MIMO Rel-19

RAN1#116

9.2 NR MIMO Phase 5

Please refer to RP-234007 for detailed scope of the WI.

[116-R19-MIMO] – Eko (Samsung)

Email discussion on Rel-19 MIMO Phase 5

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2400725 Rel-19 NR MIMO Phase 5: initial rapporteur assessment Moderator (Samsung)

9.2.1 Enhancements for UE-initiated/event-driven beam management

R1-2400507 Enhancements for UE-initiated/event-driven beam management MediaTek Inc.

· Proposal 1: For Rel-19 UE-initiated/event-driven beam management, both reporting delay reduction and beam application delay reduction should be considered

· Proposal 2: Support at least event-driven triggering manner for beam reporting

o An event-driven beam report will be triggered when the event condition(s) is satisfied

o Study the event condition and the corresponding use case(s)

· Proposal 3: For UL medium and container of UE-initiated/event-driven beam reporting, support to report via UCI on PUSCH/PUCCH

· Proposal 4: For UE-initiated/event-driven beam reporting, at least support pre-configured transmission occasion(s)/resource(s) dedicated for beam reporting

o Pre-configured transmission occasion(s)/resource(s) dedicated for beam reporting could be CG-PUSCH or PUCCH

· Proposal 5: For UE-initiated/event-driven beam reporting, support to reserve the pre-configured transmission occasion(s)/occasion(s) dedicated for beam reporting via an UL indication

o Whether or not the pre-configured transmission occasion(s)/resource(s) dedicated for beam reporting is reserved by a UE is determined according to an UL indication before the pre-configured transmission occasion(s) dedicated for beam reporting

§ A UE is expected to transmit a beam report in PUSCH/PUCCH on a reserved pre-configured transmission dedicated for beam reporting

§ A UE is not allowed to transmit PUSCH/PUCCH on a non-reserved pre-configured transmission dedicated for beam reporting

o FFS: design of UL indication

· Proposal 6: In a UE-initiated/event-driven beam reporting instance, support reporting of a synchronization state along with each reported pair of a RS index (e.g., SSBRI/CRI) and a value of L1 measurement quantity (e.g., L1-RSRP/L1-SINR).

o The synchronization state indicates “synchronized” or “unsynchronized” for a TCI state associated with the reported RS

§ If the reported RS is indicated as “synchronized”, the associated TCI state is applicable after the beam reporting instance

§ If the reported RS is indicated as “unsynchronized”, the associated TCI state will be applicable after the UE receives the first SSB transmission after reporting

§ FFS: How to determine the association between a measurement/reporting RS and a TCI state

Decision: The document is noted.

R1-2400912 Enhancements for UE-initiated beam management Ericsson

· Proposal 1: The event(s) for UE-initiated beam reporting are specified in the standard, i.e., the events are not up to UE implementation.

· Proposal 2: RAN1 provides RAN2 with a high-level description of a minimum set of events by RAN2#127.

· Proposal 3: RAN2 specifies a minimum set of events for UE-initiated beam reporting based on high-level input from RAN1.

· Proposal 4: It should be possible to configure more than one event in parallel.

· Proposal 5: RAN1 studies postprocessing of measurements used for events, and ways to control the amount of event triggering.

· Proposal 6: The NW provides UL resources for the UE-initiated report dynamically.

· Proposal 7: The UE requests UL resources for the transmission of the UE-initiated report using legacy mechanisms.

· Proposal 8: The legacy beam report content, complemented by information about the triggering event, is the starting point for the report content.

· Proposal 9: RAN1 to study how to reduce the number of spurious beam measurement reports, e.g., by measurement filtering.

· Proposal 10: After sending a UE-initiated beam report, the UE would store the QCL properties of the SSB associated with the reference signal that triggered the measurement report.

Decision: The document is noted.

R1-2400049 Discussion on UE-initiated/event-driven beam management Spreadtrum Communications

R1-2400100 Enhancements for UE-initiated/event-driven beam management FUTUREWEI

R1-2400104 On UE initiated/event-driven beam management Huawei, HiSilicon

R1-2400161 On UE/Event-Driven Beam Management InterDigital, Inc.

R1-2400194 Enhancements for UE-initiated/event-driven beam management Lenovo

R1-2400204 Enhancements for UE-initiated/event-driven beam management Transsion Holdings

R1-2400237 Discussion on UE-initiated/event-driven beam management vivo

R1-2400278 Discussion on enhancements for UE-initiated/event-driven beam management ZTE

R1-2400321 Discussion on enhancements for UE-initiated/event-driven beam management CMCC

R1-2401469 Enhancements for event driven beam management Intel Corporation (rev of R1-2400381)

R1-2400428 Discussion on enhancements for UE-initiated/event-driven beam management CATT

R1-2400467 Discussion on enhancements for UE-initiated or event-driven beam management NEC

R1-2400553 Enhancements for UE-initiated/event-driven beam management xiaomi

R1-2400623 Discussions on UE-initiated/event-driven beam management OPPO

R1-2400726 Views on Rel-19 UE-initiated/event-driven beam management enhancements Samsung

R1-2400771 Discussion on enhancements for UE-initiated/event-driven beam management Fujitsu

R1-2400848 Considerations on UE initiated beam management Sony

R1-2400917 UE-initiated beam management LG Electronics

R1-2400933 Discussions on enhancements for UE-initiated/event-driven beam management Ruijie Network Co. Ltd

R1-2400938 Enhancements to facilitate UE-initiated/event-driven beam management Nokia, Nokia Shanghai Bell

R1-2400959 Enhancements for UE-initiated/Event-Driven Beam Management Panasonic

R1-2401007 Views on UE-initiated/event-driven beam management Apple

R1-2401044 Enhancements for UE-initiated/event-driven beam management Sharp

R1-2401049 Discussion on enhancements for UE-initiated/event-driven beam management Hyundai Motor Company

R1-2401078 Enhancements for UE-initiated/event-driven beam management NICT

R1-2401112 Discussion on enhancements for UE-initiated/event-driven beam management NTT DOCOMO, INC.

R1-2401187 Discussion on UE-initiated/event-driven beam management ITRI

R1-2401201 Discussion on UE initiated beam management ASUSTeK

R1-2401226 Enhancements for UE-initiated/event-driven beam management ETRI

R1-2401243 Views on enhancements for UE-initiated/event-driven beam management KDDI Corporation

R1-2401256 Discussion on enhancements for UE-initiated or event-driven beam management Google

R1-2401271 Enhancements for UE-initiated/event-driven beam management CEWiT

R1-2401436 UE-initiated/event-driven beam management Qualcomm Incorporated

R1-2401625 Moderator Summary #1 on UE-initiated/event-driven beam management Moderator (ZTE)

Presented in Tuesday session

R1-2401681 Moderator Summary #2 on UE-initiated/event-driven beam management Moderator (ZTE)

From Wednesday session

Agreement

On UE-initiated/event-driven beam report, at least of following aspects should be included:

Trigger-event detection for beam reporting by UE

UE monitors RS to assess if a beam-reporting trigger condition has been met
FFS: Trigger condition for declaring beam-reporting event

Beam-report transmission by UE

Signaling contents in the beam report
Down-selection one or more options (strive for one) between the following options as signaling medium/container for beam report transmission

MAC-CE
UCI
Others are not precluded.

On UE-initiated/event-driven beam report, the following aspects may be included:

UE requesting UL resource(s) for the beam report
UE notifying transmission of beam report
gNB preconfigured resources

Other procedure(s) as required

R1-2401787 Moderator Summary #3 on UE-initiated/event-driven beam management Moderator (ZTE)

From Thursday session

Agreement

On UE-initiated/event-driven beam reporting, regarding trigger-event detection for beam reporting, RAN1 further study at least the following aspects: quality metrics, event-definition and threshold.

Further study trigger events, including the following example as a starting point

Event-1: Quality of the current beam is worse than a certain threshold.
Event-2: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the current beam.
Event-3: Quality of a new beam is better than a certain threshold.
Event-4: Quality of the current beam is worse than a threshold 1, and quality of at least one new beam is better than a threshold 2.
Others are not precluded.

Note: Companies are encouraged to provide details on procedure (e.g. how it is used) related to their preferred event

Agreement

On UE-initiated/event-driven beam reporting, at least support L1-RSRP as a measurement quantity on SSB for intra-cell and inter-cell, and periodic CSI-RS for beam management

· Notes: measurement results may be contained in the beam report and/or used as quality metric(s) to initiate/trigger the reporting.

· FFS: Semi-persistent CSI-RS and aperiodic CSI-RS.

· FFS: Whether/how to support L1-SINR measurement, assuming legacy RS or RS combination (e.g., CMR only, CMR+ZP/NZP-IMR) for Rel-16 SINR is reused.

· FFS: Whether/how to specify filtering operation for L1-RSRP.

Agreement

On UE-initiated/event-driven beam reporting, regarding signaling content(s), at least support DL RS resource indicator and L1-RSRP

FFS: Study and decide whether additional contents can be supported.
FFS: L1-RSRP format, e.g., absolute and/or differential value.
Note: Above does not imply to preclude discussion on L1-RSRP filtering.
The actual reported content depends on the triggering event

Support of one or multiple events will be discussed separately

9.2.2 CSI enhancements

Including support for up to 128 CSI-RS ports on FR1 and UE reporting enhancement for CJT

R1-2400105 On 128 CSI-RS ports and UE reporting enhancement Huawei, HiSilicon

Proposal 1: Support CSI-RS ports with CSI-RS resources, with P/K ports in each resource.

Proposal 2: Support Type-I/Type-II codebook refinement with 48/64/96/128 CSI-RS ports, and

· For 64 CSI-RS ports, 2 32-port CSI-RS resources are configured;

· For 128 CSI-RS ports, 4 32-port CSI-RS resources are configured;

· For 48 CSI-RS ports, 2 24-port CSI-RS resources are configured;

· For 96 CSI-RS ports, 3 32-port CSI-RS resources are configured.

Proposal 3: For Type-I/Type-II codebook refinement, CSI-RS ports from 3000 to 3000+X-1 are mapped to multiple CSI-RS resources, where X is the supported number of CSI-RS ports larger than 32.

Proposal 4: Support the combinations of and in Table 2 for larger than 32 ports.

Proposal 5: Enhance both Rel-16 eType-II and Rel-17 FeType-II codebooks to support up to 128 CSI-RS ports for CSI enhancement.

Proposal 6: Support combinations of and in Table 2 for Rel-16 eType-II codebook.

Proposal 7: Complexity reduction for high rank should be supported, especially for 64/128 antenna ports.

Proposal 8: The limitation on the number of CSI-RS ports per resource in current spec. should be relaxed to support following configurations:

· For CSI-RS resources, up to 32 CSI-RS ports per resource;

· For CSI-RS resources, up to 16 CSI-RS ports per resource;

· For CSI-RS resources, up to 8 CSI-RS ports per resource.

Proposal 9: For multi-beam CSI measurement, transmitting less CSI-RS resources than the total number of analog beams can be considered to reduce the CSI-RS overhead.

Proposal 10: For multi-beam CSI reporting, support to report the CRIs and associated RIs/PMIs/CQIs for up to 6 beams.

Proposal 11: For multi-beam CSI reporting, support both Type I and Type II codebook.

Proposal 12: Multi-beam joint CSI reporting should be supported to reduce the reporting overhead.

Proposal 13: Support the reporting of frequency /delay offset between TRPs.

Proposal 14: Support reporting of the phase offsets of the DL measured channels between TRPs for joint DL/UL reciprocity calibration.

Proposal 15: Support to reuse TRS for frequency and delay offset measurement.

Proposal 16: Support to configure multiple resource sets where each set corresponds to one TRP.

Proposal 17: Support a reference resource/time for reporting of frequency/time offsets.

Proposal 18: Adopt Table 9 in Appendix C as working assumption for LLS evaluation.

Decision: The document is noted.

R1-2400939 CSI enhancement for NR MIMO Phase 5 Nokia, Nokia Shanghai Bell

· Proposal 1: Regarding CSI extension for up to 128 CSI-RS ports, support the following combinations of : (8,4), (16,2), (8,8) and (16,4) with oversampling .

· Proposal 2: Regarding the CSI Resource Setting linked to a CSI report for up to 128 CSI-RS ports, for both Type-I and Type-II extensions, support a single CSI-RS resource set with up to 32-port resources.

· Proposal 3: Regarding the CSI-RS resource aggregation for a CSI report for up to 128 CSI-RS ports, for both Type-I and Type-II extensions, support a simple mapping of the ports across the resources to the PMI ports following the order in which the resources are configured in the resource set.

· Proposal 4: Regarding the CSI-RS resource set configured to support up to 128 ports, consider the same timing restrictions adopted for NCJT and CJT resource setting, i.e., the resources are configured in the same slot or two adjacent slots.

· Proposal 5: For Type-I codebook extension for up to 128 ports, consider extending the set of orthogonal beams for the selection of the second beam.

· Proposal 6: For Type-I codebook extension for up to 128 ports, with Mode 1, consider a simple codebook extension as a starting point, obtained by increasing the values of .

· Proposal 7: For Type-I codebook extension for up to 128 ports, with Mode 1, consider extending the candidate beams for the second beam by reusing the existing beam selection indicators to identify the first beam and to identify an cluster for the second beam, and introducing a new indicator to locate the second beam within this cluster.

· Proposal 8: For Type-I codebook extension for up to 128 ports, with Mode 1, consider extending the candidate beams for the second beam by using an extended Type-II-style beam selection mechanism, where the legacy indicators and of Type-II are reused to identify the first beam and an cluster for the second beam and a new indicator is introduced to identify the second beam within this cluster.

· Proposal 9: For Type-I codebook extension for up to 128 ports, with Mode 2, consider a simple codebook extension as a starting point, obtained by increasing the values of .

· Proposal 10: For Type-I codebook extension for up to 128 ports, with Mode 2, consider extending the candidate beam groups for the second beam group by reusing the existing beam group selection indicators to identify the first beam group and to identify an cluster of the second beam group, and introducing a new indicator to locate the second beam group within this cluster.

· Proposal 11: For Type-I codebook extension for up to 128 ports, with Mode 2, consider extending the candidate beam groups for the second beam group by using an extended Type-II-style beam selection mechanism, where the legacy Type-II indicators and are reused to identify the first beam group and an cluster for the second beam group and introducing a new indicator to identify the second beam group within this cluster.

· Proposal 12: Regarding Type-I and Type-II extensions for up to 128 ports, for the EVM assumptions, consider the following transmit array and port layouts. For 64 ports: and . For 128 ports: and .

· Proposal 13: For Rel-16 Type-II codebook refinement supporting up to 128 ports, support spatial domain codebook extension for , and the selection of beams of length . For the remaining codebook description, reuse Rel-16 Type-II codebook.

· Proposal 14: For Rel-16 Type-II codebook refinement supporting up to 128 ports, evaluate the trade-off between performance and feedback overhead for the existing parameter combinations and determine if any additional parameter value restrictions are needed.

· Proposal 15: No extension of Rel-17 Type-II PS is needed because 32 pairs of angles and delays per UE are sufficient to capture the spatial and frequency characteristics of a DL channel for a single TRP.

· Proposal 16: For the extension of CRI-based CSI reporting for up to 128 ports, consider extending the existing CRI-based reporting for Type-I codebook only.

· Proposal 17: For the extension of CRI-based CSI reporting for up to 128 ports, regarding the reporting format, reuse the solution adopted for Rel-17 NCJT with one or more CSI(s), each corresponding to a CRI, reported in the same report.

· Proposal 18: For the evaluation methodology of inter-TRP frequency offset measurement and reporting, model the frequency errors for the TRPs as i.i.d. random variables, uniformly distributed within the frequency range determined by the minimum frequency error requirements of Table 6.5.1.2-1 of TS 38.104.

· Proposal 19: For inter-TRP frequency offset measurement and reporting, support measurement configuration from a single TRS set per TRP.

· Proposal 20: For the evaluation methodology for inter-TRP frequency offset measurement and reporting, maximum likelihood (ML) estimation of frequency offsets for each TRP can be assumed, obtained from measurements of two or four TRS resources of the same TRS set, depending on TRS configuration.

· Proposal 21: For the evaluation methodology of inter-TRP timing offset measurement and reporting, model the relative time alignment error (TAE) between TRPs in an inter-site scenario as i.i.d. random variables, uniformly distributed between 0 and one CP length.

Decision: The document is noted.

R1-2400050 Discussion on CSI enhancements Spreadtrum Communications

R1-2400162 On Extension of CSI Ports InterDigital, Inc.

R1-2400195 Discussion on CSI enhancements Lenovo

R1-2400205 Discussion on CSI enhancement for 128 CSI-RS ports Transsion Holdings

R1-2400238 Discussion on Rel-19 CSI enhancements vivo

R1-2400279 Discussion on CSI enhancements ZTE

R1-2400322 Discussion on CSI enhancements CMCC

R1-2400382 CSI enhancements for MIMO Intel Corporation

R1-2400397 CSI Enhancement for NR MIMO Google

R1-2400429 Discussion on CSI enhancements in Rel-19 CATT

R1-2400471 Discussion on CSI enhancements NEC

R1-2400508 CSI enhancements to support up to 128 CSI-RS ports MediaTek Inc.

R1-2400512 CSI enhancements TCL

R1-2400522 Discussion on CSI enhancements Honor

R1-2400554 Discussion on CSI enhancement for larger scale transmit antenna ports and CJT xiaomi

R1-2400624 CSI enhancements for Rel-19 MIMO OPPO

R1-2400658 Discussion on CSI enhancement for R19 MIMO evolution China Telecom

R1-2400728 Views on Rel-19 CSI enhancements Samsung

R1-2400753 CSI enhancements for large antenna arrays and CJT Ericsson

R1-2400772 Discussion on Rel-19 CSI enhancements Fujitsu

R1-2400849 Views on CSI enhancements Sony

R1-2400918 Discussions on CSI enhancements LG Electronics

R1-2400957 UE Reporting Enhancement for CJT Panasonic

R1-2401008 Views on R19 MIMO CSI enhancement Apple

R1-2401045 CSI enhancements Sharp

R1-2401113 Discussion on CSI enhancements NTT DOCOMO, INC.

R1-2401244 CSI enhancements for Rel.19 MIMO Fraunhofer IIS, Fraunhofer HHI

R1-2401254 Discussion on CSI enhancements KDDI Corporation

R1-2401272 Discussion on Type-II codebook refinement for 128 port CSI-RS CEWiT

R1-2401357 Views on CSI Enhancements for MIMO Phase 5 AT&T

R1-2401437 CSI enhancements for up to 128 ports and UE-assisted CJT with non-ideal TRP synchronization Qualcomm Incorporated

R1-2401480 Overview of CSI Enhancements for NR MIMO Evolution Kyocera (rev of R1-2400817)

R1-2401574 Moderator Summary for Monday offline session on Rel-19 CSI enhancements Moderator (Samsung)

R1-2400727 Moderator summary on Rel-19 CSI enhancements Moderator (Samsung)

From Tuesday session

Agreement

For the Rel-19 NR Type-I/II codebook refinement and CRI-based CSI for up to 128 CSI-RS ports, reuse the EVM agreed for Rel-18 NR Type-II Doppler codebooks (cf. R1-2205289) for SLS with the following refinement:

Center frequencies can be replaced by the following options (companies should state their assumption): 3.5GHz, 4.9GHz, 6GHz, 7GHz.
Companies should state their assumptions on TXRU structure and the associated TXRU-to-port virtualization for >32 ports
The UEs can be placed both indoor (with 80% probability, 3kmph) and outdoor (with 20% probability, companies should state the assumed UE speed)
Lower RU can also be assumed (companies should state the assumed RU)
Companies should state the assumed traffic models and ISD

Agreement

For the Rel-19 NR CJT calibration reporting, reuse the EVM agreed for Rel-18 NR Type-II CJT codebooks (cf. R1-2205289) for SLS with the following refinement:

Adding ISD=500m as an option for inter-site CJT
Delay offsets caused by propagation delays from the UE to the TRPs and, whenever applicable, the ISI incurred by the composite (summed across selected TRP(s)) channel impulse response should be modelled/accounted

In addition, initial timing offsets among TRPs can be included, e.g. from TR 38.855 for positioning or uniformly distributed [-0.5CP:0.5CP]

Per-TRP frequency offset (relative to the UE) is modelled as a uniform random variable with [-x:x]

Companies should state the assumed value of x, e.g. 0.05ppm, 0.1ppm (per Table 6.5.1.2-1 of TS.38.104)

For TDD, per-TRP DL/UL phase misalignment is modelled as a uniform random variable with [-y:y] where y is {p}
For TDD, per-TRP DL/UL timing misalignment is modelled as a uniform random variable with [-z:z]

Companies should state the assumed value of z, e.g. 65ns (from RAN4)

For FDD scenarios, Rel-18 Type-II CJT codebook is assumed
For TDD scenario, SRS-based (e.g. SVD) precoding is assumed
Companies should state the assumed sub-carrier spacing, e.g. 15kHz, 30kHz

Agreement

For the Rel-19 NR CJT calibration reporting, use the following EVM for LLS with the following refinement:

· Purpose: alternative to SLS to observe the impact of misalignment and gain by proposed solutions, as the frequency offset/time misalignment have impacts in granularities of subcarrier/symbol levels

Parameter	Value
Duplex, Waveform	TDD, OFDM
Carrier Frequency	3.5 GHz
Channel Model	CDL-C channel model in TR 38.901
Delay Spread	300ns
BS antenna configuration	(M, N, P, Mg, Ng; Mp, Np) = (2, 8, 2, 1, 1; 2, 8), (dH, dV) = (0.5, 0.8)
TRP number	2
UE antenna configuration	(M, N, P, Mg, Ng; Mp, Np) = (1, 2, 2, 1, 1; 1, 2), (dH, dV) = (0.5, 0.5)
UE number	1, 4
MCS	Link Adaption
Bandwidth	20RB, 145RB
Numerology	14 OFDM symbol per slot, 30kHz SCS
MIMO Rank	rank = 2 per UE
UE speed	3km/h
Precoding granularity	2RB, 4RB, 8RB, 16RB, 32RB
SRS periodicity	10ms
DMRS	Type 2 DMRS, double-symbol, or Type 1 DMRS
DL DMRS channel estimation	LMMSE channel estimation
Frequency offset	Uniformly distributed delay difference between [0, x], companies should state the assumed value of x, e.g., 0.05ppm, 0.1ppm.
Delay difference	a uniformly distributed delay difference between [0, y], companies should state the assumed value of y, e.g., CP length, 1.67us, 65ns.

Agreement

For the Rel-19 Type-I and Type-II codebook refinement for up to 128 CSI-RS ports, regarding NZP CSI-RS resource aggregation to attain 32 < P (or P_CSI-RS)≤ 128, support aggregating at least K=2, 3, or 4 legacy NZP CSI-RS resources with equal number of ports

FFS (by RAN1#116bis): Mapping from CSI-RS resource index/port index per resource and port index to CSI/PMI calculation, also considering co-existence with pre-Rel-19 UEs
FFS (by RAN1#116bis): whether the Rel-18 CJT CMR restrictions (where all resources shall be located within 2 consecutive slots) are reused, or additional restriction(s) are introduced (e.g. PCoffset, CDM type, RS density, TD (co-located in a slot)/FD locations, QCL, …)
FFS (by RAN1#116bis): Whether legacy resource configuration for interference measurement is reused, or additional restriction(s) are introduced
FFS: Whether all the K CSI-RS resources are associated with a same CSI-RS resource set or not
Note: If the supported number of ports does not require aggregation of 3 resources, K=3 can be removed

Agreement

For the Rel-19 Type-II codebook refinement for up to 128 CSI-RS ports, in accordance to the WID, the following enhancement areas are supported:

· Adding new (N₁, N₂) values for the Rel-16 eType-II regular and Rel-18 Type-II Doppler regular codebooks where 2N₁N₂ (>32) is the total number of CSI-RS ports across aggregated NZP CSI-RS resources, and O₁=O₂=4

o FFS: How to configure the aggregated NZP CSI-RS resources when AP-CSI-RS resources are configured as CMR for Rel-18 Type-II Doppler codebooks

· Adding new P_CSI-RSvalues for Rel-17 FeType-II Port Selection (PS) codebook where P_CSI-RS(>32) is the total number of CSI-RS ports across aggregated NZP CSI-RS resources

There will be separate UE feature groups for each of the enhanced codebooks.

Note: Per WID objective 2b,

No other legacy codebook design aspects (such as SD/FD/DD basis design including O₁/O₂, W₂/combining coefficient design, codebook parameter definitions and respective values) can be modified.
Only RI=1-4 is supported

Agreement (modified on Thursday as shown)

For the Rel-19 aperiodic standalone CJT calibration reporting, the following use cases are assumed:

For per-TRP delay offset reporting:

Use case 1.1: TRP selection
Use case 1.2: delay offset compensation for at least one TRP to ensure the CJT-composite delay spread doesn’t exceed a pre-defined dynamic range/threshold

For per-TRP frequency offset (FO) reporting:

Use case 2.1: TRP selection
Use case 2.2: per-TRP FO compensation at NW side

~~For per-TRP DL/UL phase/Tx-Rx timing misalignment reporting:~~

~~Use case 3.1: TRP selection~~
~~Use case 3.2: per-TRP DL/UL phase compensation at NW side for reciprocity (e.g. using both CSI-RS and SRS for measurement)~~
~~Use case 3.3:~~ ~~per-TRP FO compensation at NW side (e.g. assisting precoding change until a new PMI updated)~~
~~Use case 3.4: timing compensation for DL/UL Tx-Rx timing misalignment (reciprocity)~~

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, support the following:

· The UE is configured with N_TRP NZP CSI-RS resources/resource sets via higher-layer (RRC) signalling where N_TRP{1, 2, 3, 4}

o FFS (by RAN1#116bis): Whether further restriction(s) on applicable NZP CSI-RS resources/resource sets need to be introduced (e.g. number of ports, only TRS with multiple resource sets, TD/FD locations, QCL assumptions)

· For the purpose of CJT calibration reporting, decide, by RAN1#116bis, from the following

o Opt1: The UE reports for all the configured N_TRP NZP CSI-RS resources/resource sets

o Opt2: The UE reports for N out of N_TRP NZP CSI-RS resources/resource sets where the selection of N resources/resource sets is dynamically signalled by the NW to the UE

o Opt3: The UE reports for N out of N_TRP NZP CSI-RS resources/resource sets where the selection of N resources/resource sets is performed by the UE and included in the CSI report

· Interference measurement is not supported, hence neither CSI-IM nor NZP CSI-RS resource for interference measurement can be configured (analogous to Rel-18 TDCP)

· FFS: One-part or two-part UCI on PUSCH (analogous to Rel-18 TDCP)

· The priority of the CSI report(s) is the same as CSI report(s) not carrying L1-RSRP or L1-SINR (analogous to Rel-18 TDCP)

R1-2401649 Moderator Summary for Tuesday offline session on Rel-19 CSI enhancements Moderator (Samsung)

R1-2401650 Moderator Summary#2 on Rel-19 CSI enhancements: ROUND 2 Moderator (Samsung)

From Wednesday session

Agreement

D_n,offset is a B-bit indicator representing the delay offset associated with the n-th CSI-RS resource/resource set

For the reference CSI-RS resource/resource set nref, the value of D_nref,offset is assumed 0 and not reported

FFS (by RAN1#116bis): Whether nref is fixed, NW-configured, or is included in the report (selected by the UE)

The value of D_n,offset indicates the interval which the delay offset falls into

Down-select, by RAN1#116bis, from the following

Alt1: is uniformly spaced between 0 and A_D, i.e. , with
Alt2: is uniformly spaced between -A_D and A_D, i.e. , with

Each interval corresponds to a codepoint, and and/or represent ‘out-of-range’
FFS (by RAN1#116bis): supported quantization alphabet(s) (including A_D, M)

d_nis a 1-bit indicator associated with the n-th CSI-RS resource/resource set, indicating whether the measured delay offset, plus delay spread, is inside or outside a pre-defined range/interval

FFS (RAN1#116bis): The pre-defined range(s), e.g. CP length or its multiple

FFS: Detailed UCI design on codepoint encoding details
FFS: The need for a new QCL assumption

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, in addition to the already agreed use cases, the following use cases are assumed:

For per-TRP DL/UL Rx-Tx phase misalignment reporting:

Use case 3.1: TRP selection
Use case 3.2: per-TRP DL/UL Rx-Tx phase compensation at NW side for reciprocity (e.g. using both CSI-RS and SRS for measurement)

Agreement

For the Rel-19 Type-I codebook refinement for up to 128 CSI-RS ports, at least for RI=1-4, study and decide, by RAN1#116bis, from the following:

· Scheme1 (baseline): Adding new (N₁, N₂) values for the Rel-15 Type-I single-panel codebook where 2N₁N₂ (>32) is the total number of CSI-RS ports across aggregated NZP CSI-RS resources

o FFS: Whether to further down-select between mode-1 (L=1) and mode-2 (L=4)

o FFS: For rank-3/4, follow legacy mechanisms for <16 ports, or for >=16 ports

· Scheme2: Adding new (N₁, N₂) values where 2N₁N₂ (>32) is the total number of CSI-RS ports across aggregated NZP CSI-RS resources, and

o W₁ structure:

§ For each layer, reuse legacy Rel-16 eType-II SD basis with L=1 to determine the DFT-based SD basis candidates

· FFS: Whether the indication of selected SD basis indices follows Rel-16 eType II or Rel-15 Type I

§ For 4≥RI>1, L=1 SD basis vector is independently selected for different layers

· FFS: SD basis selection restriction to reduce SD overhead for RI>4

o W₂ structure: Layer-specific inter-polarization M-PSK co-phasing where M is further down-selected from {2, 4, 8, 16}

o FFS: Common SD vector selection for a pair of layers (reduced total number of bits for SD basis vector selection); layer multiplexing via orthogonal polarization co-phasing for the layer pairs with common SD vector (reduced number of bits for co-phasing indication for the layer pairs with common SD vector).

o FFS: Additional support for L>1

· Scheme2B: Adding new (N₁, N₂) values where 2N₁N₂ (>32) is the total number of CSI-RS ports across aggregated NZP CSI-RS resources, and

o W₁ structure:

§ For each layer, determine L=1 DFT-based SD basis candidate

· FFS: Whether the indication of selected SD basis indices follows Rel-16 eType-II or Rel-15 Type-I

§ For 4≥RI>1, L=1 SD basis vector is independently selected for different layers

§ FFS: Common SD vector selection for a pair of layers (reduced total number of bits for SD basis vector selection), SD basis selection restriction to reduce SD overhead for RI>4

o W₂ structure:

§ Option 1: Layer-specific inter-polarization amplitude and phase scaling (single scaling coefficient per polarization)

· FFS: WB/SB amplitude and phase reporting.

§ Option 2: Layer-specific intra-polarization (two scaling coefficients per polarization) amplitude and phase scaling.

· FFS: WB/SB amplitude and phase reporting.

§ FFS: Rel-15 3-bit WB amplitude and M-PSK co-phasing and M is further down-selected from {2, 4, 8, 16}.

· Scheme3: Adding new (N₁, N₂) values where 2N₁N₂ (>32) is the total number of CSI-RS ports across aggregated NZP CSI-RS resources, and

o W₁ structure:

§ Reuse legacy Rel-16 eType-II SD basis with L>1 to determine the DFT-based SD basis candidates, and indication of SD basis indices follows Rel-16 eType-II

§ For 4≥RI>1, L>1 SD basis vectors are commonly selected across layers

· FFS: SD basis selection restriction to reduce SD overhead for RI>4

o W₂ structure:

§ Option 1: Layer-specific sub-band SD basis selection (1 out of L) and inter-polarization M-PSK co-phasing where M is further down-selected from {2, 4, 8, 16}

§ Option 2: Layer-specific wideband SD basis linear combination and inter-polarization scaling coefficient (e.g., amplitude scaling + M-PSK co-phasing) where M is further down-selected from {2, 4, 8, 16}

· Scheme4: Using legacy Rel-15 Type-I codebook including legacy (N₁, N₂) values per NZP CSI-RS resource (or port group) where the PMI (associated with W₁ and W₂) is calculated according to

o W1 structure: Reuse legacy Rel-15 Type-I SD basis with L=1 or L=4 for either each or some of the NZP CSI-RS resources (or port groups)

o W2 structure: inter-NZP CSI-RS resource (or port group) co-phasing along with reusing legacy Rel-15 Type-I inter-polarization co-phasing per NZP CSI-RS resource (or port group)

§ inter-CSI-RS resource (or port group) co-phasing is used to combine the different PMIs to come up with a single precoder with >32 ports

· Scheme5: Adding new (N₁, N₂) values where 2N₁N₂ (>32) is the total number of CSI-RS ports across aggregated NZP CSI-RS resources, and extending the set of orthogonal beams for the selection of the second beam based on the Rel-15 Type-I single-panel codebook

o (i_1,1, i_1,2) is used to refer to the 1^st beam as in legacy Rel-15 Type-I

o The 2^nd beam is selected from the extended set of orthogonal beams of size:

o FFS: whether to apply any restrictions to the extended orthogonal set of beams

· Scheme6: Adding new (N₁, N₂) values where 2N₁N₂ (>32) is the total number of CSI-RS ports across aggregated NZP CSI-RS resources, and

o Beam(s) is(are) selected for each antenna group or NZP CSI-RS resource.

o Inter-group (or CSI-RS resource) co-phasing along with inter-polarization co-phasing per group (or CSI-RS resource) are used to combine different beam(s), FFS using scalar quantization or vector quantization for the co-phasings

FFS (by RAN1#116bis): Down-select (O₁, O₂) value between (2,2) and (4,4), whether (O₁, O₂) and/or (q₁, q₂) is layer-common or layer-specific

FFS (by RAN1#116bis): Whether extension of Rel-15 Type-I MP codebook for Rel-19 Type-I is also supported

FFS (by RAN1#116bis): Whether to introduce larger L values (e.g. 6, 8, 10)

FFS: Whether to refine CBSR design to reduce RRC overhead

Agreement

For the Rel-19 Type-II codebook refinement for up to 128 CSI-RS ports,

Fully reuse the legacy Rel-16 eType-II design (and for PS codebook, the Rel-17 FeType-II PS design) for UCI omission rules
On the supported parameter combinations, decide, by RAN1#116bis, whether further restriction on the the legacy Rel-16 eType-II design (and for PS codebook, the Rel-17 FeType-II PS design) to reduce/limit PMI overhead and/or UE complexity is necessary
On the definition and detailed design of UCI parameters, fully reuse the legacy Rel-16 eType-II design (and for PS codebook, the Rel-17 FeType-II PS design), except for SD basis selection indication

On SD basis selection indication, decide, by RAN1#116bis, whether refinement on the legacy Rel-16 eType-II design (and for PS codebook, the Rel-17 FeType-II PS design) is necessary to reduce UE memory requirements

On CBSR, decide, by RAN1#116bis, whether refinement on the legacy Rel-16 eType-II design (and for PS codebook, the Rel-17 FeType-II PS design) is necessary to reduce RRC overhead (including moving (N1,N2) configuration out from CBSR IE)
Further study the rules on CPU occupation, resource counting, and Z2/Z2’ in conjunction with Rel-19 Type-I

Agreement

For the Rel-19 Type-I codebook refinement for up to 128 CSI-RS ports, support also RI=5-8, with lower priority than RI=1-4:

FFS: Reduced complexity design, whether to reuse legacy RI=5-8 structure, based on the outcome of RI=1-4

Agreement

For the Rel-19 Type-I and Type-II codebook refinement for up to 128 CSI-RS ports, at least support the legacy time-domain behaviours for CSI reporting (and the applicable CSI-RS time-domain behaviors). That is,

For Rel-19 Type-I:

Aperiodic CSI (channel(s) and multiplexing rules follows legacy)
Periodic CSI (channel(s) and multiplexing follows legacy), hence wideband PMI only
Semi-persistent CSI (channel(s) and multiplexing rules follows legacy)

For Rel-19 Type-II:

Semi-persistent CSI on PUSCH (channel(s) and multiplexing rules follows legacy)
Aperiodic CSI (channel(s) and multiplexing rules follows legacy)

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, in accordance to the WID, extend the Rel-15 CRI-based CSI reporting as follows:

A UE is configured to measure K_S>1 NZP CSI-RS resources with equal number of ports, with up to 32 ports per NZP CSI-RS resource

Note: The maximum number of ports per NZP CSI-RS resource for a given value of K_S will be discussed separately

Containing the information of M “quadruplets” {(CRI_n, RI_n, PMI_n, CQI_n), n=0, …, M–1} in one CSI reporting instance where the value range of M (≤K_S) is {1, …, min(X, K_S)}

FFS (by RAN1# 116bis): The supported value(s) of X (candidates are 2, 4, 6, K_S)
FFS (by RAN1# 116bis): Whether the value of M is NW-configured via higher-layer (RRC) signalling, or UE-selected (as a part of CSI report), or a combination of the two

A same legacy codebook (with up to 32 ports) is configured for (associated with) all M “quadruplets”

FFS: detailed UCI design/optimization (e.g. overhead reduction)

FFS: Whether solution to allow CSI reporting for larger number of CSI-RS resources across multiple CSI reports is supported

FFS: whether further restriction(s) on CMR configuration is needed, including relation with IMR

FFS: the packing order of the information of M “quadruplets”, CSI omission rule

FFS: Whether all the K CSI-RS resources are associated with a same CSI-RS resource set or not

FFS: Whether K_S, maximum # ports per resource, and X depend on codebook type

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, the supported combinations of K_S value and the maximum number of ports per NZP CSI-RS resource are as follows:

FFS: UE capability on K_S and the number of ports per resource

K_S	Maximum # ports per resource
2, 3, 4	32
5, 6, 7, 8	16

Conclusion

The Rel-17 NCJT CSI is not extended to accommodate the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports.

Agreement (further modified on Thursday as shown in red)

For the Rel-19 Type-II codebook refinement based on Rel-16 eType-II and Rel-18 Type-II Doppler for up to 128 CSI-RS ports, as well as Rel-19 Type-I codebook refinement for up to 128 CSI-RS ports, support the following (N₁, N₂) values:

Total # CSI-RS ports across aggregated resources (=P)	(N₁, N₂)
48	(8,3)
48	(6,4)
64	(16,2)
64	(8,4)
128	(16,4)
128	(8,8)

The support of total # CSI-RS ports across aggregated resources (=P) and (N₁, N₂) is subject to UE capability.

For the Rel-19 Type-II codebook refinement based on Rel-16 eType-II regular codebook, the (N₁,N₂) values for P=64 are supported as a part of the respective basic feature, while those for P=48 and P=128 are supported as two separate UE capabilities
For the Rel-19 Type-II codebook refinement based on Rel-18 Type-II Doppler regular codebook, the (N₁,N₂) values for P=64 are supported as a part of the respective basic feature, while those for P=48 and P=128 are supported as two separate UE capabilities

R1-2401723 Moderator Summary for Thursday offline session on Rel-19 CSI enhancements Moderator (Samsung)

R1-2401724 Moderator Summary#3 on Rel-19 CSI enhancements: ROUND 3 Moderator (Samsung)

From Thursday session

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, in addition to the already agreed use cases, the following use cases are assumed for study:

Use case 3.3: For TDD reciprocity, timing offset report for at least one pair of TRPs to assist TRP synchronization (i.e. to align TRP inherent timing without propagation delay)

Whether there is any spec support associated with this use case is FFS

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, given the N_TRP configured NZP CSI-RS resources/resource sets and the selected N resources/resource sets, support reporting, in one CSI reporting instance, {FO_n , n=0, 1, …, N – 1, n≠nref}, where FO_n denotes the measured frequency offset associated with the n-th CSI-RS resource/resource set relative to the reference CSI-RS resource/resource set nref

For the reference CSI-RS resource/resource set nref, the value of FO_nref is assumed 0 and not reported

FFS (by RAN1#116bis): Whether nref is fixed, NW-configured, or is included in the report (selected by the UE)
FFS (by RAN1#116bis): whether the UE assumes that the measured and reported per-TRP frequency offsets can include Doppler shift (if existent) associated with the reference CSI-RS resource/resource set nref
FFS: Measurement resource/resource set for FO reporting

Down-select, by RAN1#116bis, from the following

Alt1. The value of FO_n indicates a uniformly quantized FO between –A_FO and A_FO, or 0 and A_FO

FFS (by RAN1#116bis): supported quantization alphabet(s) (including A_FO and resolution) for FO_n

Alt2. The value of FO_n indicates the interval which the FO falls into

Alt2A: is uniformly spaced between -A_FO and A_FO, i.e.
Alt2B: is uniformly spaced between 0 and A_FO, i.e.

FFS: whether “out-of-range” value/interval is needed, or whether TRP selection value is needed
FFS: If N<N_TRP, the rest (N_TRP–N) resources/resource sets are indicated with a state “out of range”
FFS: Detailed UCI design
FFS: The need for a new QCL assumption
FFS the unit of A_FO: e.g. absolute (e.g. in Hz) or relative (e.g. in ppm/ppb relative to carrier frequency, or fraction of SCS), dependence on RS configuration

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, given the N_TRP configured NZP CSI-RS resources/resource sets and the selected N resources/resource sets, study and decide, by RAN1#116bis, whether to support reporting, in one CSI reporting instance, {_n,m n=0, 1, …, N – 1, n≠nref, m=0,1,…,M-1}, where _n,m denotes the measured phase offset between the n-th CSI-RS resource/resource set and the reference CSI-RS resource/resource set/ nref for the m-th frequency unit

FFS: whether M>1 (sub-band reporting) is needed or not (M=1, i.e. wideband reporting)

For the reference CSI-RS resource/resource set nref, the value of _nref is assumed 0 and not reported

FFS (by RAN1#116bis): Whether nref is fixed, NW-configured, or is included in the report (selected by the UE)

The value _n,m indicates a uniformly quantized phase between –A_ and A__, or 0 and A__

FFS (by RAN1#116bis): supported quantization alphabet(s) (including A_ and resolution) for _n,m

FFS: Detailed UCI design

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, regarding the supported codebook(s) for calculating CQI/PMI/RI on each of the M CRI(s), decide, in RAN1#116bis, between the two alternatives:

Alt1: only Rel-15 Type-I Single Panel codebook
Alt2: Rel-15 Type-I Single Panel codebook and the Rel-16 eType-II codebook

Agreement

For the Rel-19 Type-II refinement based on Rel-17 FeType-II PS, support the following P_CSI-RS value(s) {48, 64}.

· For the Rel-19 Type-II codebook refinement based on Rel-17 FeType-II PS, P_CSI-RS =64 is supported as a part of the respective basic feature, while P_CSI-RS =48 is supported as a separate UE capability.

9.2.3 Support for 3-antenna-port codebook-based transmissions

R1-2400625 Discussion on 3-antenna-port codebook-based transmissions OPPO

· Proposal 1: Following non-coherent codebooks involving different transmission layers can be used for 3-antenna-port codebook-based transmission.

Transmission layers	Precoding matrix
Single layer
Two layers
Three layers

· Proposal 2: TPMI field could be 2 or 3bits for 3-antenna-port transmission

o For maxRank equals to 1, TPMI field could be 2 bits for DFT-s-OFDM and CP-OFDM.

o For maxRank equals to 2 or 3, TPMI field could be 3 bits for CP-OFDM.

· Proposal 3: Following two alternatives are considered to achieve 3-port SRS resource

o Alt 1: Adapt a 4-port SRS resource to function as a 3-port SRS resource.

§ A predefined rule is required to utilize three of the four SRS ports.

o Alt 2: Combine 1-port and/or 2-port SRS resources to achieve a 3-port SRS resource.

§ Further study is required on the configuration of the SRS resource set and SRI enhancement.

Decision: The document is noted.

R1-2400163 On Support of CB-based UL for 3TX UE InterDigital, Inc.

· Proposal 1: 3TX sounding procedure is based on the 4-port SRS resources with the mapping of 3TX to the 4 ports.

· Proposal 2: An SRS resource set for 3TX is configured with 4-port SRS resources, where .

· Proposal 3: Study the UE behaviour for power control with 3TX.

· Proposal 4: The baseline precoders for 3TX ‘nonCoherent’ are:

o Single layer:

o Two layers:

o Three layers: .

· Proposal 5: Rel-19 specifies new codebooks for 3TX which include TPMIs for 1-, 2-, and 3-layer transmission configured with the ‘nonCoherent’ codebook subset.

Decision: The document is noted.

R1-2400051 Discussion on 3-antenna-port codebook-based transmissions Spreadtrum Communications

R1-2400106 On codebook for 3-antenna-port UL transmission Huawei, HiSilicon

R1-2400196 Support for 3-antenna-port codebook-based transmissions Lenovo

R1-2400206 Support for 3-antenna-port codebook-based transmissions Transsion Holdings

R1-2400239 Discussion on 3-antenna-port codebook-based uplink transmissions vivo

R1-2400280 Discussion on 3-antenna-port codebook-based transmissions ZTE

R1-2400323 Discussion on support for 3-antenna-port codebook-based transmissions CMCC

R1-2400383 Support for 3Tx UL MIMO Intel Corporation

R1-2400398 Uplink 3 Port Codebook based Transmission Google

R1-2400430 Discussion on 3-antenna-port codebook-based transmissions CATT

R1-2400472 Discussion on 3-antenna-port codebook-based transmissions NEC

R1-2400509 Support for 3-antenna-port codebook-based transmissions MediaTek Inc.

R1-2400513 Support for 3-antenna-port codebook-based transmissions TCL

R1-2400523 Discussion on 3-port codebook-based transmissions Honor

R1-2400555 Discussion on the support of 3-antenna-port CB based transmissions xiaomi

R1-2400729 Views on Rel-19 3-antenna-port codebook-based transmissions Samsung

R1-2400773 Discussion on uplink enhancement for UE with 3Tx Fujitsu

R1-2400850 Considerations on support for 3-antenna-port codebook-based transmissions Sony

R1-2400919 Discussions on 3-antenna-port codebook-based transmissions LG Electronics

R1-2400940 On the support for 3-antenna-port codebook-based transmissions Nokia, Nokia Shanghai Bell

R1-2401009 Views on R19 3Tx codebook based transmission Apple

R1-2401046 Support for 3-antenna-port codebook-based transmission Sharp

R1-2401077 Support for 3 Tx UL transmissions Ericsson

R1-2401114 Discussion on support for 3-antenna-port codebook-based transmissions NTT DOCOMO, INC.

R1-2401438 3 Tx UL MIMO transmissions Qualcomm Incorporated

R1-2401578 FL Summary Support for 3TX CB-based Uplink; First Round Moderator (InterDigital, Inc.)

From Tuesday session

Agreement

For non-coherent uplink precoding by a 3TX UE, at least following precoders are supported for single-layer transmission.

Agreement

For non-coherent uplink precoding by a 3TX UE, at least following precoders are supported for two-layer transmission.

, ,

Agreement

For non-coherent uplink precoding by a 3TX UE, at least following precoders are supported for three-layer transmission.

Agreement

For SRS configuration supporting codebook-based UL transmission by a 3TX UE, down-select one of

· Alt1 – Support configuration of X 4-port SRS resources in a resource set where one the ports is muted

· Alt2 – Support configuration of X SRS resources with equal/unequal number of ports (e.g. 2 + 1 or 1 + 1 + 1) in a resource set,

The value for X is FFS, and it will be determined according to the selected alternative.

Agreement

For a 3TX UE, down-select one of the following options for the number of PTRS ports,

· Option-1: A single PTRS port is supported.

· Option-2: Up to 2 PTRS port may be configured.

Agreement

For a 3-antenna-port codebook-based UL transmission, study PTRS-DMRS association.

Agreement

For a 3-antenna-port codebook-based UL transmission, study power split for each port of SRS and PUSCH.

Agreement

For codebook-based uplink transmission by a 3TX UE, support full-power Mode 0, subject to UE capability.

Conclusion

There is no consensus in RAN1 to support antenna switching for 3TX UE in Rel-19

Agreement

For performance evaluation of 3TX UE, adopt the following Table as the reference EVM for LLS evaluation

· Companies may provide additional evaluation results per their case of interest

· LLS is optionally used for 3Tx UL evaluation, if needed

Parameter	Value
Carrier Frequency	3.5 GHz
Waveform	CP-OFDM
SCS	30 KHz
System bandwidth	20 MHz, 100 MHz
Scheduled PRBs	5, 25, 50, 260 PRBs
gNB RX antenna setup and port layouts (𝑀,𝑁,𝑃,𝑀𝑔,𝑁𝑔,𝑀𝑝,𝑁𝑝)	(8,8,2,1,1,4,8) with (𝑑H, 𝑑V) = (0.5, 0.8)𝜆 (4,4,2,1,1,4,4) with (𝑑H, 𝑑V) = (0.5, 0.8)𝜆 (2,2,2,1,1,2,2) with (dH , dV ) = (0.5, 0.5)λ
UE speed	3 Km/h
Number of Layers	Adaptive, Fixed (reported by company)
AMC	Adaptive, Fixed (reported by company)
DMRS configuration	Type 1; 1 front loaded + 1 additional symbol
Channel estimation	Real
Channel Model	CDL-A (30ns), CDL-B (100ns), CDL-C (300ns)

R1-2401579 FL Summary Support for 3TX CB-based Uplink; Second Round Moderator (InterDigital, Inc.)

From Wednesday session

Agreement

For performance evaluation of 3TX UE, adopt the following Table as the reference EVM for SLS evaluation.

· Companies may provide additional evaluation results per their case of interest.

Note: The considered EVM is to be used as a baseline set of assumption for future potential studies related to 3TX.

Parameter	Value
Frequency range	3.5 GHz
Multiple access	OFDMA
Numerology	14 CP-OFDM symbol slot SCS , 30 KHz
Scenario	eMBB: Dense Urban (200m), 3.5GHz Outdoor FWA: UMa (500m), 3.5GHz
UE Outdoor/Indoor (%)	eMBB: 80%, 20% Outdoor FWA: 100%, 0%
System bandwidth	20 MHz, 100 MHz
gNB RX antenna setup and port layouts (𝑀,𝑁,𝑃,𝑀𝑔,𝑁𝑔,𝑀𝑝,𝑁𝑝)	(8,8,2,1,1,4,8) with (𝑑H, 𝑑V) = (0.5, 0.8)𝜆 (4,4,2,1,1,4,4) with (𝑑H, 𝑑V) = (0.5, 0.8)𝜆 Optional: Classical: two 8x1 xpols, 4λ apart; 4 TXRUs tilt=[104°]
gNB antenna radiation pattern parameters	- Outdoor/Indoor Per 38.901, Table 7.3-1
gNB receiver noise figure	5dB
gNB receiver	MMSE-IRC
gNB scheduler	Single user with proportional fair
Modulation	- Up to 64 QAM - Up to 256QAM
MIMO scheme	SU-MIMO with rank adaptation
UE speed	3 Km/h
UE antenna config	eMBB: - Xpol+1pol; isotropic ULA - Xpol+1pol; 110°, 4 dBi Outdoor FWA: - Xpol+1pol; isotropic ULA - 3 directional 1pol: 110°, 4 dBi
Traffic model	- FTP model 1: Packet size 500KB, RU= 50% and suggested low/high RU of values of 20% and 70% - Full buffer (optional)
Suggested benchmarking	Rel-15 2Tx non-coherent
Precoder granularity	Wideband
Power control	Open loop, - alpha = 0.8 - P₀= -50, -80 dBm to be selected according to the deployment scenario
UE power rating	eMBB: 23 dBm, UL FPTx mode 0 or Rel-15 power scaling Outdooe FWA: 31 dBm, UL FPTx mode 0
Metric	UL mean-user throughput, 5%-ile and 95%-ile UPT

Agreement

For performance evaluation of 3TX UE, consider following reference configurations,

A linear array (1D) of single-polarized antenna configuration with a spacing of 0.5λ,

For example: |

A configuration of a cross-polarized and a single-polarized antennas,

For example:

Agreement

For SRS configuration supporting codebook-based UL transmission by a 3TX UE, one SRS resource set is configured for single TRP operation.

R1-2401798 FL Summary Support for 3TX CB-based Uplink; Third Round Moderator (InterDigital, Inc.)

From Thursday session

Agreement

For codebook-based transmission by a 3TX UE,

Only PUSCH antenna ports 1000, 1001, 1002 are used
Option- 2: Subject to UE capability, up to 2 PTRS ports may be configured in PTRS-UplinkConfig,

FFS whether a single bit or 2 bits are used for PTRS-DMRS association indication.

Above is only for single panel transmission.

R1-2401580 Recommended Direction on 3TX CB-based Uplink in RAN1#116bis Moderator (InterDigital, Inc.)

9.2.44 Enhancement for asymmetric DL sTRP/UL mTRP scenarios

R1-2400281 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios ZTE, China Telecom

Proposal 1: Support to configure a second separate closed loop for SRS in SRS resource set, i.e., the higher layer parameter srs-PowerControlAdjustmentStates in SRS-ResourceSet.

Proposal 2: Support to introduce a closed loop indicator field with 1-bit size in DCI format 2_3 to indicate TPC command for SRS power adjustment if configured with two separate closed loops, regardless of whether the higher layer parameter SRS-CarrierSwitching is configured or not.

Proposal 3: Support to configure pathloss offset for PL-RS in UL TCI state.

Proposal 4: Support to further justify whether/how to apply dedicated pathloss offset values for different UL channels/signals.

Proposal 5: Support to further discuss whether/how to dynamically indicate/update pathloss offset values for UL transmission towards to UL TRP(s).

Proposal 6: For asymmetric DL sTRP/UL mTRP scenarios, at least separate DL/UL TCI indication framework should be supported for both cases of ‘Rel-17 unified TCI for sTRP/ICBM’ and ‘Rel-18 unified TCI for sDCI based mTRP’.

· To clarify TCI indication for the above cases, e.g.,

o When Rel-17 unified TCI applied for sTRP/ICBM: one DL TCI state + one UL TCI state

§ Note: Rel-17 mechanism(s) to update spatial relation of the SRS not sharing the indicated Rel-17 TCI state can be used to update UL TCI state of SRS for DL CSI acquisition.

o When Rel-18 unified TCI applied for sDCI based mTRP: one DL TCI state + up to two UL TCI states

Decision: The document is noted.

R1-2401115 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios NTT DOCOMO, INC.

Proposal 1: For asymmetric DL sTRP/UL mTRP scenarios, at least the following Rel-17/18 unified TCI framework should be supported.

· For intra-cell TCI state indication:

o Rel-17 unified TCI for single TRP or Rel-18 unified TCI for single DCI based multi-TRP/panel.

· For inter-cell (intra-DU) TCI state indication:

o Rel-17 unified TCI for single TRP.

· Note: Rel-18 unified TCI for multi-DCI based multi-TRP/panel is not suitable, because gNB needs to send PDCCH corresponding to each coresetPoolIndex, which is not aligned with the scenario of “DL sTRP” in the WID.

Proposal 2: Support configuration of “one or two SRS resource set(s) with same CL-PC adjustment state as PUSCH” and the other “one or two SRS resource set(s) with CL-PC adjustment state separate from PUSCH” in a BWP in a CC.

· Introduce 2^nd CL-PC adjustment state separate from PUSCH (e.g. k={0,1}).

· Index of {1^st, 2^nd} CL-PC adjustment state separate from PUSCH is configured per SRS resource set.

Proposal 3: Support {1^st, 2^nd} CL-PC adjustment states separate from PUSCH as independent feature from SRS carrier switching.

· Note: This feature can be applied regardless of the configuration of PUSCH or SRS carrier switching.

· Introduce new RRC parameter to enable {1^st, 2^nd} CL-PC adjustment state separate from PUSCH per SRS resource set.

o Support both srs-TPC-PDCCH-Group = {typeA, typeB}.

Proposal 4: Whether to support joint configuration of the following features in a CC should be discussed.

· UE feature 1: Legacy one CL-PC adjustment state separate from PUSCH for SRS carrier switching.

· UE feature 2: New {1^st, 2^nd} CL-PC adjustment states separate from PUSCH.

Proposal 5: DCI format 2_3 is used to indicate TPC commands for CL-PC adjustment states separate from PUSCH.

· Alt.1: One group common DCI (e.g. DCI format 2_3) can indicate two TPC commands associated with both 1^st and 2^nd CL-PC adjustment states separate from PUSCH in a CC.

o Introduce 2^nd TPC command (2-bit) for the 2^nd CL-PC adjustment state separate from PUSCH.

· Alt.2: One group common DCI (e.g. DCI format 2_3) can indicate one TPC command associated with either 1^st or 2^nd CL-PC adjustment state separate from PUSCH in a CC.

o Alt.2-1: Introduce 1-bit to indicate which one of {1^st, 2^nd} CL-PC adjustment states separate from PUSCH is associated to the TPC command.

o Alt.2-2: Implicit indication of which one of {1^st, 2^nd} CL-PC adjustment states separate from PUSCH is associated to the TPC command (e.g. by SRS request field).

Proposal 6: MAC CE/DCI can indicate PL-offset value, depending on which UL/DL TRP UE transmits. The number of PL-offset values configured in a BWP/CC is at least larger than or equal to 4.

Proposal 7: PL-offset configuration should be applied to all UL CH/RS (i.e. SRS, PUSCH, PUCCH, PRACH) after RRC connection set up.

Proposal 8: For PUSCH/PUCCH/SRS, PL-offset is configured in a UL TCI state.

· If PL-offset is configured in a UL TCI state applied to PUSCH/PUCCH/SRS, and if the UL TCI state is applied to the UL transmission, UE calculates PL using the PL-offset value when UE transmits the PUSCH/PUCCH/SRS.

Proposal 9: For PRACH, a set of PL-offsets is configured in PRACH-Config.

· PDCCH can indicate one of PL-offset values for PDCCH order PRACH.

Proposal 10: Support two TA for single DCI based multi-TRP/panel or single TRP.

· Reuse Rel-18 spec. of two TA for multi-DCI based multi-TRP/panel and remove the restriction that coresetPoolIndex needs to be configured.

Decision: The document is noted.

R1-2400052 Enhancements for asymmetric DL sTRP/UL mTRP scenarios Spreadtrum Communications

R1-2400107 On power control enhancements for DL sTRP and UL mTRP deployment Huawei, HiSilicon

R1-2400164 On Asymmetric mTRP Deployment InterDigital, Inc.

R1-2400197 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Lenovo

R1-2400240 Discussion on asymmetric DL sTRP/UL mTRP scenarios vivo

R1-2400267 Discussion on asymmetric DL sTRP/UL mTRP scenarios TCL

R1-2400324 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios CMCC

R1-2400384 Enhancements for asymmetric DL/UL scenarios Intel Corporation

R1-2400431 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios CATT

R1-2400468 Discussion on enhancements for asymmetric DL sTRP and UL mTRP scenarios NEC

R1-2400510 Enhancement for asymmetric DL sTRP/UL mTRP scenarios MediaTek Inc.

R1-2400521 Enhancement for asymmetric DL sTRP UL mTRP scenarios Ericsson

R1-2400556 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios xiaomi

R1-2400626 Enhancements on asymmetric DL sTRP/UL mTRP scenarios OPPO

R1-2400659 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios China Telecom

R1-2400730 Views on Rel-19 asymmetric DL sTRP/UL mTRP scenarios Samsung

R1-2400774 Discussion on UL-only mTRP operation Fujitsu

R1-2400851 Considerations on enhancement for asymmetric DL sTRP/UL mTRP scenarios Sony

R1-2400920 Discussions on asymmetric DL sTRP/UL mTRP scenarios LG Electronics

R1-2400941 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Nokia, Nokia Shanghai Bell

R1-2400958 Enhancement for Asymmetric DL sTRP/UL mTRP Scenarios Panasonic

R1-2401010 Views on R19 enhancement for asymmetric DL sTRP/UL mTRP Apple

R1-2401047 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Sharp

R1-2401050 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios Hyundai Motor Company

R1-2401472 Discussion on enhancement for asymmetric DL sTRP/UL mTRP deployment scenarios NTPU (rev of R1-2401052)

R1-2401257 Discussion on enhancement for asymmetric DL sTRP and UL mTRP scenarios Google

R1-2401439 Enhancement for asymmetric DL sTRP and UL mTRP deployment scenarios Qualcomm Incorporated

R1-2401489 Summary #1 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

Presented in Tuesday session

R1-2401490 Summary #2 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

From Wednesday session

Agreement

For the asymmetric DL sTRP/UL mTRP deployment scenarios, support to associate a UL TCI state with a PL offset:

When a UL TCI state associated with a PL offset is applied for the PUSCH/PUCCH/SRS transmission, the UE shall calculate the Tx power of the PUSCH/PUCCH/SRS based on the DL PL RS and PL offset associated with this UL TCI state.

Reuse the legacy uplink power control formulation by replacing legacy PL with UL PL which is derived from the DL PL RS and the PL offset.
FFS: The UE can update UL PL in a way that new UL PL = current UL PL + an update delta indicated by the NW.

Note: it does not intend to increase the number of maintained PLs per cell.
FFS: whether to support associating joint TCI state (if supported) with a PL offset.

Further study whether/how to apply a PL offset on PDCCH-order PRACH transmission too.

FFS: how to determine the Tx beam of PRACH towards UL TRP
Note: this does not imply to support 2 TA for single-DCI based system.

Agreement

To facilitate the asymmetric DL sTRP/UL mTRP deployment scenarios, support ~~configuring~~ two closed-loop PC adjustment states for SRS in one CC, both of which are separate from that of the PUSCH.

Agreement

Study how to indicate TPC command for those two SRS CLPC adjustment states through DCI when the UE is configured two SRS CLPC adjustment states, down-select from the following options:

Option 1: enhance the legacy DCI format 2_3 of higher layer parameter srs-TPC-PDCCH-Group = typeA;
Option 2: enhance the legacy DCI format 2_3 of higher layer parameter srs-TPC-PDCCH-Group = typeB;
Option 3: enhance the legacy DCI format 2_3 of higher layer parameter srs-TPC-PDCCH-Group = typeA and typeB;
Option 4: enhance DCI format 1_1 and/or 0_1 to indicate TPC for SRS CLPC adjustment states
Option 5: enhance the legacy DCI format 2_3 by introducing a new Type for higher layer parameter srs-TPC-PDCCH-Group
Option 6: new DCI format to indicate TPC for SRS CLPC adjustment states
Other options are not precluded.

For the Options1, 2, 3 and 5, consider at least the following Alts as possible examples:

Alt1: In DCI format 2_3, add one additional TPC command for each CC configured with two SRS CLPC adjustment states,

the first TPC command is associated with the first SRS CLPC adjustment state and the second TPC command is associated with the second SRS CLPC adjustment state.

Alt2: Introduce one 1-bit closed-loop-indicator field for each TPC command in DCI format 2_3

This 1-bit closed-loop-indicator indicates the first SRS CLPC adjustment state or the second SRS CLPC adjustment state.

Alt3: use two different TPC-SRS-RNTIs for DCI format 2_3:

DCI format 2_3 with CRC scrambled with the first TPC-SRS-RNTI and the second TPC-SRS-RNTI indicates the TPC command for the first and second SRS CLPC adjustment state, respectively.

Alt4: Implicit method:

Agreement

To support two SRS CLPC adjustment states, study and possibly down-select at least one from the following Alts:

Alt1: SRS CLPC adjustment state is associated with SRS resource set
Alt2: When the parameter srs-PowerControlAdjustmentStates is set to 'separateClosedLoop', closedLoopIndex-r17 in the TCI state indicates one of the SRS CLPC adjustment states
Alt3: Add one extra parameter in P0AlphaSet-r17 of TCI state to indicate one of those two SRS CLPC adjustment states
Alt4: SRS CLPC adjustment state is associated with SRS resource usage type

Note: Other alternatives are not precluded

R1-2401491 Summary #3 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

From Thursday session

Agreement

Down-select one from the following alternatives:

Alt1: Use only RRC to update the PL offset associated with the UL TCI state
Alt2: In addition to RRC, MAC-CE can be used to update the PL offset associated with the UL TCI state

FFS: Details on MAC CE

Agreement

For the asymmetric DL sTRP/UL mTRP deployment scenarios, separate DL/UL TCI state mode of Rel-17/18 unified TCI framework can be configured for both FR1 and FR2.

· Joint TCI state mode can be configured at least for FR1

RAN1#116-bis

9.2 NR MIMO Phase 5

Please refer to RP-240087 for detailed scope of the WI.

[116bis-R19-MIMO] – Eko (Samsung)

Email discussion on Rel-19 MIMO Phase 5

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

9.2.1 Enhancements for UE-initiated/event-driven beam management

R1-2402017 On UE initiated/event-driven beam management Huawei, HiSilicon

R1-2402051 Enhancements for UE-initiated/event-driven beam management FUTUREWEI

R1-2402063 Discussion on enhancements for UE-initiated/event-driven beam management ZTE

R1-2402079 Rel-19 UE/Event-Driven Beam Management InterDigital, Inc.

R1-2402098 Discussion on UE-initiated/event-driven beam management Spreadtrum Communications

R1-2402138 Enhancements for event driven beam management Intel Corporation

R1-2402155 Enhancements for UE-initiated/event-driven beam management MediaTek Inc.

R1-2402235 Discussion on UE-initiated/event-driven beam management vivo

R1-2402321 Discussions on UE-initiated/event-driven beam management OPPO

R1-2402376 Discussion on UE-initiated/event-driven beam management CATT

R1-2402457 Views on Rel-19 UE-initiated/event-driven beam management Samsung

R1-2402496 Enhancements for UE-initiated/event-driven beam management Lenovo

R1-2402529 Discussion on enhancements for UE-initiated/event-driven beam management Langbo

R1-2402558 Discussion on enhancements for UE-initiated/event-driven beam management CMCC

R1-2402632 UE-initiated beam management LG Electronics

R1-2402659 Enhancements for UE-initiated/event-driven beam management Xiaomi

R1-2402684 Enhancements for UE-initiated/event-driven beam management Transsion Holdings

R1-2402718 Discussion on UE initiated report ASUSTeK

R1-2402721 Discussion on UE-initiated/event-driven beam management Honor

R1-2402758 Discussion on enhancements for UE-initiated or event-driven beam management NEC

R1-2402791 Discussion on enhancements for UE-initiated/event-driven beam management Fujitsu

R1-2402806 Discussion on UE-initiated/event-driven beam management ITRI

R1-2402838 Enhancements to facilitate UE-initiated/event-driven beam management Nokia

R1-2402874 Views on UE-initiated beam management Apple

R1-2402961 Discussion on UE initiated beam management Sony

R1-2402982 Enhancements for UE-initiated beam management Ericsson

R1-2403015 Enhancements for UE-initiated/event-driven beam management ETRI

R1-2403055 Enhancements for UE-initiated/event-driven beam management CEWiT

R1-2403068 Discussions on enhancements for UE-initiated/event-driven beam management Ruijie Networks Co. Ltd

R1-2403088 Discussion on enhancements for UE-initiated or event-driven beam management Google

R1-2403108 Enhancements for UE-initiated/event-driven beam management Sharp

R1-2403113 Enhancements for UE-initiated/event-driven beam management Panasonic

R1-2403187 UE-initiated/event-driven beam management Qualcomm Incorporated

R1-2403237 Discussion on enhancements for UE-initiated/event-driven beam management NTT DOCOMO, INC.

R1-2403354 Views on enhancements for UE-initiated/event-driven beam management. KDDI Corporation

R1-2402711 Offline summary for Rel-19 MIMO UEIBM Moderator (ZTE)

R1-2402712 Moderator Summary #1 on UE-initiated/event-driven beam management Moderator (ZTE)

Presented in Monday session

R1-2402713 Moderator Summary #2 on UE-initiated/event-driven beam management Moderator (ZTE)

From Tuesday session

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, following modes are supported:

· Mode A (dynamically scheduling UCI by gNB):

o Step 1: UE transmits a first PUCCH (one-bit/multi-bit) to request a resource for a second UL channel to carry beam report

§ FFS: Request format, e.g., SR or a new UCI type.

o Step 2: UE detects the DCI format to indicate a resource for a second UL channel to carry beam report.

o Step 3: Beam report is transmitted in second UL channel.

§ FFS: Details on the second UL channel, e.g., whether the second UL channel is PUCCH, PUSCH or both

o This option is basic UE capability (i.e. all UE supporting UE-initiated/event-driven beam reporting should support this feature).

o No new DCI format is introduced.

· Mode B (UCI in pre-configured resource(s) for second UL channel):

o Step 1: UE transmits a first PUCCH (one-bit/multi-bit) notifying a second UL channel to carry beam report

§ FFS: Notification format, e.g., SR or a new UCI type.

o Step 2: UE transmits the beam report in the second UL channel.

§ FFS: Details on the second UL channel, e.g., whether the second UL channel is PUCCH, PUSCH or both

o The notification in Step1 is in a separate reporting instance from the beam report in Step 2.

FFS: Whether UE receives acknowledge information with response to each step for all options

For above procedures, cross-CC beam reporting is supported for both options.

FFS: Details.

R1-2402714 Moderator Summary #3 on UE-initiated/event-driven beam management Moderator (ZTE)

From Wednesday session

Agreement (updated as shown in red in Thursday session)

On UE-initiated/event-driven beam reporting, regarding trigger-event detection for beam reporting, at least support Event-2: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the current beam.

At least L1-RSRP is supported as quality metrics used for Event-2

FFS: How the L1-RSRP is used to determine the triggering event (e.g. timer, counter, filter coefficient)
FFS: Whether the network controls how the L1-RSRP is used to determine the triggering event

~~Regarding RS measurement for the current beam for Event-2, down-select one or more of the following:~~

~~Option-2a (implicit manner): The RS for current beam is implicitly derived from a QCL RS of indicated TCI state.~~
~~Option-2c (explicit manner): The RS for current beam is explicitly configured by RRC or MAC-CE.~~

Regarding RS measurement for the new beam for Event-2, down-select one or more of the following:

Option-3a (explicit manner): The RS(s) for new beam(s) are explicitly configured by RRC (e.g., reusing legacy configuration of RS measurement or in TCI-State) or MAC-CE
Option-3b (implicit manner): The RS(s) for new beam(s) are implicitly derived from QCL RS(s) of activated TCI state(s).
Option-3c (implicit manner): The RS(s) for new beam(s) are implicitly derived from QCL RS(s) of configured TCI state(s).

~~FFS: Whether/how to specify the relationship between above RS measurement options for new and current beam(s).~~
Note-1: ‘New/current beam’ is for discussion purpose.
Note-2: Other trigger events/quality metrics (e.g., L1-SINR) are not precluded.
Note-3: For above implicit manner(s), if there are two QCL RSs in a TCI state, the measurement RS is derived from RS w.r.t. QCL-TypeD, if applicable.

Agreement

On UE-initiated/event-driven beam reporting, regarding Event-2, the threshold value is RRC configured.

R1-2403690 Summary #4 on UE-initiated/event-driven beam management Moderator (ZTE)

From Thursday session

Agreement

On UE-initiated/event-driven beam reporting, regarding Event-2, ‘current beam’ is a beam corresponding to the indicated TCI state.

· Regarding RS measurement for the current beam for Event-2, Option-2a is supported:

o Option-2a (implicit manner): The RS for current beam is implicitly derived from a QCL RS of indicated TCI state.

§ FFS: The RS for current beam can be either the QCL RS in the indicated TCI state or the SSB which is QCLed with the QCL RS in the indicated TCI state.

o FFS: Option-2c (explicit manner): The RS for current beam is explicitly configured by RRC or MAC-CE.

§ Note: SSB or CSI-RS can be configured

Agreement

On UE-initiated/event-driven beam reporting, further study the following trigger events:

· Event-1: Quality of the current beam is worse than a certain threshold.

· Event-3: Quality of a new beam is better than a certain threshold.

· Event-4: Quality of the current beam is worse than a threshold 1, and quality of at least one new beam is better than a threshold 2.

· Event-5: Absolute value of the difference between the quality of the current beam and the quality of at least one new beam is lower than a threshold.

· Event-6: When the current beam is not in the best K>1 beams (out of configured beams for measurement and reporting).

· Event-7a: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the worst quality.

· Event-7b: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the best quality.

· Event-8: Quality of M>1 new beams, such as L1-RSRP, become a threshold value better than the current beam.

· Event-9: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the configured reference RS (can be SSB or CSI-RS).

Agreement

On UE-initiated/event-driven beam reporting, regarding UL signaling content(s) of L1-RSRP report depending on Event-2, in a report instance, the following options are provided for down-selection (other options are not precluded) in RAN1#117

Option-1 (variable size): N beam(s) are reported in the report instance, where N {1, 2, ..., N_max}

The N beam(s) should satisfy the condition of Event-2
N_max is configured by gNB
FFS: Whether the indication of payload size should be provided additionally.

Option-1a (variable size): N beam(s) are reported in the report instance, where N {1, 2, ..., N_max}

At least one of N reported beam(s) should satisfy the condition of Event-2
N_max is configured by gNB
FFS: Whether the indication of payload size should be provided additionally.
FFS: Details on how value of N is determined by the UE

Option-1b: N beam(s) are reported in the report instance, where N {1, 2, ..., N_max}

The N beam(s) should satisfy the condition of Event-2
N_max is configured by gNB
Payload size does not vary as a function of N
FFS: Zero-padding can be provided if N is less than N_max.

Option-2: Only N=1 beam is reported in the report instance

The reported beam should satisfy the condition of Event-2

Option-3: N ≥ 1 beam(s) are reported in the report instance,

At least one of N reported beam(s) should satisfy the condition of Event-2
N is configured by gNB

Other options are not precluded.
FFS: Whether the measurement results for current beam is always reported or can be enabled by RRC.
FFS: When current beam is reported, whether the current beam is counted in the N reported beams.
The selected option shall satisfy Event-2.

9.2.2 CSI enhancements

Including support for up to 128 CSI-RS ports on FR1 and UE reporting enhancement for CJT

R1-2402018 On 128 CSI-RS ports and UE reporting enhancement Huawei, HiSilicon

R1-2402064 Discussion on CSI enhancements ZTE

R1-2402080 Rel-19 Enhancements of CSI InterDigital, Inc.

R1-2402099 Discussion on CSI enhancements Spreadtrum Communications

R1-2402127 CSI Enhancements for NR MIMO Evolution Kyocera Corporation

R1-2402139 CSI enhancements for MIMO Intel Corporation

R1-2402156 CSI enhancements to support up to 128 CSI-RS ports MediaTek Inc.

R1-2402180 Discussion on CSI enhancements TCL

R1-2402236 Discussion on Rel-19 CSI enhancements vivo

R1-2402281 CSI Enhancement for NR MIMO Google

R1-2402322 CSI enhancements for Rel-19 MIMO OPPO

R1-2402377 Discussion on Rel-19 MIMO CSI enhancements CATT

R1-2402406 CSI enhancement for NR MIMO Phase 5 Tejas Network Limited

R1-2403485 Views on Rel-19 CSI enhancements Samsung (rev of R1-2403424; rev of R1-2402460)

R1-2402497 Discussion on CSI enhancements Lenovo

R1-2402538 Discussion on Rel-19 CSI enhancements New H3C Technologies Co., Ltd.

R1-2402559 Discussion on CSI enhancements CMCC

R1-2402633 Discussions on CSI enhancements LG Electronics

R1-2402660 Discussion on CSI enhancement for up to 128 ports and CJT Xiaomi

R1-2402722 Discussion on CSI enhancements Honor

R1-2402767 Discussion on CSI enhancements NEC

R1-2402792 Discussion on Rel-19 CSI enhancements Fujitsu

R1-2403555 CSI enhancement for NR MIMO Phase 5 Nokia (rev of R1-2403452; rev of R1-2402839)

R1-2402875 Views on R19 MIMO CSI enhancement Apple

R1-2403476 CSI enhancements for large antenna arrays and CJT Ericsson (rev of R1-2402928)

R1-2402962 Further views on CSI enhancements Sony

R1-2403056 CSI Enhancements CEWiT

R1-2403109 CSI enhancements Sharp

R1-2403130 Discussion on UE reporting enhancement for CJT Panasonic

R1-2403145 Views on Rel-19 CSI enhancements AT&T

R1-2403425 CSI enhancements for >32 ports and UE-assisted CJT with non-ideal TRP synchronization Qualcomm Incorporated (rev of R1-2403188)

R1-2403238 Discussion on CSI enhancements NTT DOCOMO, INC.

R1-2403327 CSI enhancements for Rel.19 MIMO Fraunhofer IIS, Fraunhofer HHI

R1-2403365 Discussion on CSI enhancements for NR MIMO Phase 5 KDDI Corporation

R1-2402458 Moderator summary for OFFLINE discussion on Rel-19 CSI enhancements Moderator (Samsung)

R1-2402459 Moderator summary on Rel-19 CSI enhancements Moderator (Samsung)

From Monday session

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, given the N_TRP configured NZP CSI-RS resources/resource sets and the selected N resources/resource sets, support reporting, in one CSI reporting instance, {F_n,_s , n=0, 1, …, N – 1, n≠nref, s=0,1,…,S-1}, where F_n,_s denotes the measured phase offset between the n-th CSI-RS resource/resource set and the reference CSI-RS resource/resource set nref for the s-th frequency unit

S =1 is supported

FFS: whether S>1 (sub-band reporting) is also supported. For this decision, companies are encouraged to evaluate performance loss without the support of S>1 due to phase offset induced by TX-RX timing misalignment.

The value F_n,_s indicates a uniformly quantized phase between –A_F and A_F, or 0 and A_F_.

FFS: supported quantization alphabet(s) (including A_F and resolution) for F_n,_s

FFS: Detailed UCI design

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, for a given CJT calibration report of one [or more] CJT calibration report type, the nref is selected by the UE and reported as a part of the CJT calibration report

· Note: CJT calibration report type refers to the Doffset/d report, FO report, and, TDD PO report

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting of {FO_n , n=0, 1, …, N_TRP – 1, n≠nref}, the value of FO_n indicates a uniformly quantized frequency offset between 0 and A_FO.

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting of {(D_n,offset, d_n), n=0, 1, …, N_TRP – 1, n≠nref}, regarding the interval which D_n,offset falls into, is uniformly spaced between 0 and A_D, i.e. , with and represent ‘out-of-range’.

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, the UE reports for all the configured N_TRP NZP CSI-RS resources/resource sets.

· FFS (by RAN1#116bis): Whether an ‘invalid’ or ‘out-of-range’ quantization state/hypothesis is supported for all the types of CJT calibration reporting. Note that ‘out-of-range’ is supported for the (D_n,offset, d_n) reporting.

Agreement

For the Rel-19 Type-I single-panel (SP) codebook refinement for 48, 64, and 128 CSI-RS ports, for RI=1-4, support the following:

Scheme-A (based on Scheme1 in RAN1#116 agreement): Adding new (N₁, N₂) values for the Rel-15 Type-I single-panel codebook mode-1 (L=1) where 2N₁N₂ (>32) is the total number of CSI-RS ports across aggregated NZP CSI-RS resources, and for rank-3/4, follow legacy mechanisms for <16 ports

· Scheme-B (based on Scheme2 in RAN1#116 agreement): Adding new (N₁, N₂) values where 2N₁N₂ (>32) is the total number of CSI-RS ports across aggregated NZP CSI-RS resources, and

o W₁ structure:

§ For each layer, reuse legacy Rel-16 eType-II SD basis with L=1 to determine the DFT-based SD basis candidates

§ For 1<RI≤4, L=1 SD basis vector is independently selected for different layers

· The SD basis selection indication includes layer-common (q₁,q₂) and bits for each layer

· Note: This implies that each of the SD basis vectors is selected from a group of N₁N₂ orthogonal basis vectors

o W₂ structure: Layer-specific inter-polarization co-phasing with the alphabet {+1, +j, -1, -j}

FFS (RAN1#116bis): For Rel-19 Type-I SP, whether to support Mode-C based on Scheme5 in RAN1#116 agreement with L=1 for RI=2-4

FFS (RAN1#116bis): For Rel-19 Type-I SP, whether inter-polarization amplitude for Mode-B can also be supported

FFS: Discuss further if Rel-19 Type-I MP extension based on scheme 4 is needed

Agreement

For the Rel-19 Type-I single-panel (SP) codebook refinement for 48, 64, and 128 CSI-RS ports, for RI=1-4, O₁=O₂ is 4

· FFS: Additional support for O₁=O₂ is 2 when RI=1-4 (including separate UE capability)

Agreement

For the Rel-19 Type-I and Type-II codebook refinement for 48, 64, and 128 CSI-RS ports, regarding the mapping from CSI-RS resource index/port index per resource and port index to CSI/PMI calculation, support NW to configure UE with one of the following mapping methods via higher-layer (RRC) signaling,

· Mapping method 1: Sequential ordering/indexing within (1^st resource, 1^st polarization), then (2^nd resource, 1^st polarization), …, then (K^th resource, 1^st polarization), then (1^st resource, 2^nd polarization), then (2^nd resource, 2^nd polarization), …, then (K^th resource, 2^nd polarization)

· Mapping method 2: Sequential ordering/indexing within (where K*n2 = N2):

o for the 1^st polarization, (1^st n2 ports in 1^st resource, 1^st polarization), (1^st n2 ports in 2^nd resource, 1^st polarization), …, (1^st n2 ports in K^th resource, 1^st polarization), then (2^nd n2 ports in 1^st resource, 1^st polarization), (2^nd n2 ports in 2^nd resource, 1^st polarization), …, (2^nd n2 ports in K^th resource, 1^st polarization), … then (N1^th n2 ports in 1^st resource, 1^st polarization), (N1^th n2 ports in 2^nd resource, 1^st polarization), …, (N1^th n2 ports in K^th resource, 1^st polarization) ,

o and then for the 2^nd polarization, (1^st n2 ports in 1^st resource, 2^nd polarization), (1^st n2 ports in 2^nd resource, 2^nd polarization), …, (1^st n2 ports in K^th resource, 2^nd polarization), then (2^nd n2 ports in 1^st resource, 2^nd polarization), (2^nd n2 ports in 2^nd resource, 2^nd polarization), …, (2^nd n2 ports in K^th resource, 2^nd polarization), … then (N1^th n2 ports in 1^st resource, 2^nd polarization), (N1^th n2 ports in 2^nd resource, 2^nd polarization), …, (N1^th n2 ports in K^th resource, 2^nd polarization)

FFS: Exact port indexing within each CSI-RS resource or across K CSI-RS resources

FFS: Whether the following is also supported:

Mapping method 3 (for K=4): Sequential ordering/indexing within (where N1=2*n1, N2 = 2*n2):

o for the 1^st polarization, (1^st n2 ports in 1^st resource, 1^st polarization), (1^st n2 ports in 2^nd resource, 1^st polarization), then (2^nd n2 ports in 1^st resource, 1^st polarization), (2^nd n2 ports in 2^nd resource, 1^st polarization), …, then (n1^th n2 ports in 1^st resource, 1^st polarization), (n1^th n2 ports in 2^nd resource, 1^st polarization),

o for the 1^st polarization, (1^st n2 ports in 3^rd resource, 1^st polarization), (1^st n2 ports in 4^th resource, 1^st polarization), then (2^nd n2 ports in 3^rd resource, 1^st polarization), (2^nd n2 ports in 4^th resource, 1^st polarization), then (n1^th n2 ports in 3^rd resource, 1^st polarization), (n1^th n2 ports in 4^th resource, 1^st polarization),

o and then for the 2^nd polarization, (1^st n2 ports in 1^st resource, 2^nd polarization), (1^st n2 ports in 2^nd resource, 2^nd polarization), then (2^nd n2 ports in 1^st resource, 2^nd polarization), (2^nd n2 ports in 2^nd resource, 2^nd polarization), … then (n1^th n2 ports in 1^st resource, 2^nd polarization), (n1^th n2 ports in 2^nd resource, 2^nd polarization),

o and then for the 2^nd polarization, (1^st n2 ports in 3^rd resource, 2^nd polarization), (1^st n2 ports in 4^th resource, 2^nd polarization), then (2^nd n2 ports in 3^rd resource, 2^nd polarization), (2^nd n2 ports in 4^th resource, 2^nd polarization), then (n1^th n2 ports in 3^rd resource, 2^nd polarization), (n1^th n2 ports in 4^th resource, 2^nd polarization),

· Other methods are not precluded

Agreement

For the Rel-19 Type-I and Type-II codebook refinement for 48, 64, and 128 CSI-RS ports, regarding NZP CSI-RS resource aggregation to attain 32 < P (or P_CSI-RS)≤ 128, all K NZP CSI-RS resources shall be located within 1 slot or 2 consecutive slots (following legacy principle from Rel-18 Type-II CJT), and are associated with a same CSI-RS resource set:

FFS(RAN1#116bis): Whether ‘within 1 slot’ should be basic feature and ‘within 2 consecutive slots’ should be UE capability
FFS (RAN1#116bis): Verify if this can be achieved without refinement on CSI-RS resource set restrictions (i.e. same CDM type, same RE density, same starting RB for 0.5 RE/RB/port density, same number of RBs, for AP-CSI-RS same slot offset). If not, the supported refinement(s)
FFS (RAN1#116bis): Whether additional restriction(s) beyond the restrictions on the CSI-RS resources associated with a same resource set are needed (e.g. same QCL, PCoffset, PCOffsetSS)
FFS (RAN1#116bis): Extension for Rel-19 Type-II based on Rel-18 Type-II Doppler with aperiodic CMR

Agreement

For the Rel-19 Type-I and Type-II codebook refinement for 48, 64, and 128 CSI-RS ports, the legacy resource configuration for interference measurement is reused, i.e. only one NZP CSI-RS resource for interference measurement or only one CSI-IM resource can be configured where the one IM resource is associated with all the K CSI-RS resources in the CSI-RS resource set for channel measurement.

Conclusion

For the Rel-19 Type-II codebook refinement for 48, 64, and 128 CSI-RS ports, on SD basis selection indication, there is no consensus on additional spec enhancement. Therefore, the same approach as legacy (using a layer-common -bit indicator) is reused.

Note: How to trade-off memory and calculation is left to implementation

Agreement

For the Rel-19 Type-II codebook refinement for 48, 64, and 128 CSI-RS ports, on CBSR, refine the legacy CBSR as follows:

Only 1-bit hard restriction is supported (analogous to Rel-18 Type-II)
Moving (N₁, N₂) configuration out from CBSR IE and the CBSR can be optional configured

Send LS to RAN2, and subject to RAN2 consent

Group-based CBSR granularity where each bit in the CBSR is associated with a set of X₁X₂ SD basis vectors, where the set includes X₁ adjacent SD basis vectors along the N₁ direction and/or X₂ adjacent SD bases along the N₂ direction

FFS: Value(s) of X₁ and X₂ and detailed design/spec impact

FFS: Whether/how to enable shared CBSR in RRC configuration for Type-I/-II codebooks with a same (N₁,N₂).

Agreement

For the Rel-19 Type-II codebook refinement for 48, 64, and 128 CSI-RS ports based on Rel-18 Type-II Doppler codebook,

On UCI omission rules, fully reuse the legacy Rel-18 Type-II Doppler design.
On the definition and detailed design of UCI parameters, fully reuse the legacy Rel-18 Type-II Doppler design.

Agreement

For the Rel-19 Type-I codebook refinement for 48, 64, and 128 CSI-RS ports, the (N₁,N₂) values for P=64 are supported as a part of the respective basic feature, while those for P=48 and P=128 are supported as two separate UE capabilities.

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports,

For Rel-15 Type-I Single Panel codebook, M is NW-configured via higher-layer (RRC) signaling with candidate value(s) of {1, …, min(4,K_S)}

The maximum value of M is subject to UE capability

For Rel-16 eType-II, M=1 is supported

The maximum value of K_S is {1,2,3,4} and subject to UE capability

The support for Rel-16 eType-II is a separate UE capability at least from the support for Rel-19 Type-I and Type-II codebook refinements

FFS (RAN1#116bis): The support for M=2, and if so, the value of M={1, 2} is NW-configured via higher-layer (RRC) signaling, and if additional restriction(s) are needed

FFS: The determination of M reported beams

Note: Selection algorithm of CRI(s) from measurement of K_S>1 NZP-CSI-RS resources is up to UE implementation.

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, support the following time-domain behaviours:

For Rel-15 Type-I SP codebook:

Aperiodic CSI (channel(s) and multiplexing rules follows legacy)
Periodic CSI (channel(s) and multiplexing follows legacy), hence wideband PMI only
Semi-persistent CSI (channel(s) and multiplexing rules follows legacy)

For Rel-16 eType-II codebook:

Semi-persistent CSI on PUSCH (channel(s) and multiplexing rules follows legacy)
Aperiodic CSI (channel(s) and multiplexing rules follows legacy)

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, the following report quantities are supported:

‘cri-RI-PMI-CQI ‘
‘cri-RI-LI-PMI-CQI’ (only for Type-I)
FFS: ‘cri-RI-i1-CQI’ (only for Type-I)
FFS: ‘cri-RI-i1’ (only for Type-I)

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, on the configured K_S>1 NZP CSI-RS resources, reuse the legacy CMR and IMR rules for the Rel-15 CRI-based reporting. This includes:

· All the K_S NZP CSI-RS resources are associated with a same CSI-RS resource set

· K_S CSI-IM resources can be configured (implying one-to-one correspondence between K_S CMRs and K_S CSI-IMs)

FFS: Whether all the K_S NZP CSI-RS resources share a same Pcoffset and PcoffsetSS

FFS: Whether or not NZP CSI-RS resource for interference measurement can be configured. FFS further details.

R1-2403524 Moderator Summary for Tuesday OFFLINE session on Rel-19 CSI enhancements Moderator (Samsung)

R1-2403523 Moderator Summary#2 on Rel-19 CSI enhancements: ROUND 2 Moderator (Samsung)

From Tuesday session

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, assuming the Rel-17/18 unified TCI framework, regarding TCI/QCL, the following is assumed:

· Based on the legacy support of up to 2 TCI states for PDSCH-CJT.

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, regarding the applicable type(s) of the configured N_TRP NZP CSI-RS resources/resource sets when ReportQuantity is ‘cjtc-Dd’ (Doffset+d) or ‘cjtc-F’ (frequency offset), periodic TRS (‘CSI-RS for tracking’) resource set is used for each of the N_TRP NZP CSI-RS resource sets

· Extend the maximum allowed number of TRS resource sets to 4 (note: legacy supports max. 3 from Rel-18 TDCP)

· FFS: Whether all the resources across the N_TRP TRS resource sets are configured with the same bandwidth

· FFS: Whether aperiodic TRS resource set can also be used

· FFS: Whether CSI-RS for CSI can also be used

· FFS: Whether different RE locations (FDM) are supported for the RSs

· FFS: additional time separation between RSs

· FFS: The exact number of CSI-RS resource(s) within each TRS resource set

· FFS: applicable type(s) if joint reporting of both Doffset/d and FO is supported

Agreement

· FFS: Whether multi-port CSI-RS for CSI can also be used

· FFS: Whether all the ‘CSI-RS for CSI’ resources within each resource set follow the legacy pre-Rel-19 rules of CSI-RS resources associated with a same resource set, and whether only 1 or N_TRP >1 resource sets are used

· FFS: The exact number of CSI-RS resource(s) within each resource set

· FFS: Whether different RE locations (FDM) are supported for the RSs

· FFS: additional restrictions e.g. time separation between RSs, bandwidth

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, regarding phase offset reporting, the value F_n,_s indicates a uniformly quantized phase between 0 and 2p.

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, the dynamic range and resolution parameters for delay offset reporting D_n,offset, i.e. (A_D, M_D), are NW-configured via higher-layer (RRC) signalling from the following candidate values:

A_D ={0.5CP, 0.75CP, CP, 1.5CP, 2CP, , , } where CP and denote the length of the cyclic prefix according to the current specifications (for normal CP) within a slot and the SCS, respectively

FFS: Further down-selection of the above candidate values for AD, including the use of a same unit for all supported values

M_D ={32, 64}

FFS: If TDD TX/RX timing misalignment report is supported, whether different set of candidate M_D values is needed

In addition, the inside/outside range for the 1-bit indicator d_n is equal to [0, CP].

FFS: Further implicit/explicit restriction(s) on candidate value(s) depending on the CSI-RS configuration.

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, an ‘invalid’ quantization state/hypothesis is supported for frequency offset and phase offset CJT calibration reporting.

Note: already supported as ‘out-of-range’ for the (D_n,offset, d_n) reporting
FFS (RAN1#117): The need for a condition/event for ‘invalid’ to be specified as a UE procedure e.g. RSRP-based

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, at least for a CJT calibration report consisting only one type, support one-part UCI on PUSCH.

Agreement

For the Rel-19 Type-I multi-panel (MP) codebook refinement for 48, 64, and 128 CSI-RS ports, for RI=1-4, decide, by RAN1#117, whether to support Type-I multi-panel (MP) codebook refinement in Rel-19.

If supported, decide from the following alternatives:

Scheme1. Based on Rel-15 Type-I MP design directly extended with Ng=K (2, 3, and 4), and new (N₁, N₂) values
Scheme2. Based on Scheme4/6 as described in the RAN1#116 agreement

o W1 structure: Reuse legacy Rel-15 Type-I SP SD basis selection with L=1 independently for each of the K NZP CSI-RS resources

o W2 structure:

Legacy Rel-15 Type-I inter-polarization co-phasing rules independently in each resource,
Layer-common inter-resource M-PSK co-phasing, where M is further down-selected from {2,4}

FFS: Whether inter-resource co-phasing is wideband or per subband.

If so, decide, by RAN1#117, whether port mapping scheme similar to, e.g. Rel-18 Type-II CJT, needs to be specified.

Note: This topic is lower priority compared to the Rel-19 Type-I SP codebook refinement.

Conclusion

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports with RI=1-4, there is no consensus on supporting the following additional enhancements: Mode-C, inter-polarization amplitude for Scheme-B, larger values of L (>1, including 2, …, 10).

Agreement

For the Rel-19 Type-I and Type-II codebook refinement for 48, 64, and 128 CSI-RS ports, regarding NZP CSI-RS resource aggregation to attain 32 < P (or P_CSI-RS)≤ 128, support the following refinement on the K>1 CSI-RS resources associated with a same CSI-RS resource set:

Allow per-resource configuration of evenPRBs or oddPRBs for 0.5 RE/RB/port density
For AP-CSI-RS, allow resource-specific slot offset when the K NZP CSI-RS resources are located in two consecutive slots

FFS: details on how to configure/determine the slot offsets

Agreement

For the Rel-19 Type-I and Type-II codebook refinement for 48, 64, and 128 CSI-RS ports, regarding NZP CSI-RS resource aggregation to attain 32 < P (or P_CSI-RS)≤ 128, all the K>1 NZP CSI-RS resources also share the same QCL, PCoffset, and PCoffsetSS. In addition:

‘within 1 slot’ should be basic feature and ‘within 2 consecutive slots’ should be UE capability.

Agreement

For the Rel-19 Type-II codebook refinement for 48, 64, and 128 CSI-RS ports based on the Rel-18 Type-II Doppler codebook, support the following aperiodic CMR configuration:

A UE can be configured with K_DOPP = {4, 8, 12} CSI-RS resource groups for the purpose of aperiodic CMR as needed by Type-II Doppler CSI

The time separation between the first resources from two consecutive groups (=m) can be configured from {1, 2}
FFS: The need for additional restriction in time domain

Each CSI-RS resource group comprises K NZP CSI-RS resources (K defined in previous agreements) for aggregation associated with a same CSI-RS resource set assuming the agreed resource set rules for Rel-19 Type-I/II codebooks
All the K_DOPP CSI-RS resource groups are associated with a same CSI-RS resource set configuration

FFS: the determination of CSI-RS resource group that a CSI-RS resource is associated with.

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, for M>1, the M CRIs (each with bits) are separated indicated

· FFS: whether to support NW configuring/requesting the UE to report CRI/RI/PMI/CQI associated with M_R (<M) of K_S CSI-RS resources, including whether further reduction in the number of hypotheses is supported, i.e. reporting (M – M_R) CRIs (each with bits)

Agreement

For the Rel-19 Type-I SP and Type-II codebook refinements for 48, 64, and 128 CSI-RS ports via aggregating K>1 CSI-RS resources, regarding timeline, introduce two UE capabilities:

Capability 1: Reuse legacy Z/Z’ values
Capability 2: Scale the legacy timeline Z/Z’ by ceil(P/32) where P is the total number of ports across all the K aggregated CSI-RS resources

FFS: CPU occupation and active resource counting

Note:

The legacy timeline Z/Z’ for Type-I corresponds to Z1/Z1’ in Table 5.4-2 of TS38.214 for Type-I WB SP-CSI with at most 4 CSI-RS ports in a single resource without CRI, and Z2/Z2’ for other Type-I cases
The legacy timeline Z/Z’ for Type-II corresponds to Z2/Z2’

R1-2403603 Moderator Summary for Wednesday OFFLINE session on Rel-19 CSI enhancements Moderator (Samsung)

R1-2403602 Moderator Summary#3 on Rel-19 CSI enhancements: ROUND 3 Moderator (Samsung)

From Wednesday session

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, regarding frequency offset reporting, and represents an ‘invalid’ state.

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, the dynamic range and resolution parameters for frequency offset reporting FO_n, i.e. (A_FO, M_FO), are NW-configured via higher-layer (RRC) signalling from the following candidate values:

· A_FO = {0.01ppm, 0.1ppm, 0.2ppm, f, f/2, f/4,f/8, 1/(4t), 1/(8t), 1/(16t), 1/(32t), 1/(512t)} where f and t denote the SCS and duration of one OFDM symbol, respectively

o FFS: Further down-selection of the above candidate values for A_FO, including the use of a same unit for all supported values

· M_FO = {16,32}

FFS: Whether additional restriction(s) based on CSI-RS configuration is supported, including implicit configuration of quantization range.

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, the resolution parameters for _n, i.e. M_, are NW-configured via higher-layer (RRC) signalling from the candidate values {16, 32}, where .

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, regarding QCL assumptions, each of the N_TRP DL-RSs can be configured with a TCI state via RRC signaling

· ‘The DL-RS’ refers to the CSI-RS configured for CJT calibration measurement

· FFS: Whether additional constraints are needed for the TCI state of the ‘DL-RS’

Agreement

For a UE indicated with two TCI states, regarding QCL assumptions for PDSCH, at least the following are supported:

Scheme C: The PDSCH DMRS port(s) are QCLed with the DL-RS associated with the first TCI state with respect to QCL-TypeA and QCLed with the DL-RS in the second TCI state with respect to QCL-TypeA except for {Doppler shift}
Scheme D: The PDSCH DMRS port(s) are QCLed with the DL-RS associated with the first TCI state with respect to QCL-TypeA and QCLed with the DL-RS in the second TCI state with respect to QCL-TypeA except for {average delay}

Per Rel-18, the support of two TCI states is a UE capability

Agreement

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports, the UCI parameters are captured in the tables below for Scheme-A and Scheme-B:

Note: The second column includes the location of the parameters when reported with two-part UCI
FFS (RAN1#117): Select between Alt1 and Alt2 for Scheme-B

Scheme-A

Parameter	UCI	Details/description	Status
RI	Part 1	Same as Rel-15 Type-I SP: RI=v	Complete
Wideband CQI for the first TB	Part 1	Same as Rel-15 Type-I SP	Complete
Subband differential CQI for the first TB (*)	Part 1	Same as Rel-15 Type-I SP	Complete
Wideband CQI of the second TB	Part 2 Wideband	Same as Rel-15 Type-I SP Only present when v >4	Complete
Subband CQI of the second TB (*)	Part 2 Subband	Same as Rel-15 Type-I SP Only present when v >4	Complete
First SD basic vector selection indicator	Part 2 Wideband	v=1-4: Same as Rel-15 Type-I SP with the scheme following < 16-port design of Rel-15 Type-I SP codebookMode=1 v=5-8: FFS	v=1-4: Complete v=5-8: Pending
Second SD basis vector selection indicator	Part 2 Wideband	v=1-4: Same as Rel-15 Type-I SP with the scheme following < 16-port design of R15 Type-I codebookMode=1 v=5-8: FFS	v=1-4: Complete v=5-8: Pending
Inter-pol co-phase selection indicator	Part 2 Wideband or Subband (**)	v=1-4: Same as Rel-15 Type-I SP with the scheme following < 16-port design of R16 Type-I codebookMode=1 v=5-8: FFS	v=1-4: Complete v=5-8: Pending

Scheme-B

Parameter	UCI	Details/description	Status
RI	Part 1	Same as Rel-15 Type-I SP: RI=v	Complete
Wideband CQI for the first TB	Part 1	Same as Rel-15 Type-I SP	Complete
Subband differential CQI for the first TB (*)	Part 1	Same as Rel-15 Type-I SP	Complete
Wideband CQI of the second TB	Part 2 Wideband	Same as Rel-15 Type-I SP Only present when v>4	Complete
Subband CQI of the second TB (*)	Part 2 Subband	Same as Rel-15 Type-I SP Only present when v >4	Complete
SD basis oversampling (rotation) factor q₁, q₂	Part 2 Wideband	v=1-4: Values of q₁, q₂ follow Rel-16 eType-II, bit indicator v=5-8: FFS	v=1-4: Complete v=5-8: Pending
SD basis vector selection indicator for each layer	Alt1: Part 1 Alt2: Part 2 Wideband	v=1-4: - Alt1: bit indicator per layer l=1, …, RI_MAX - Alt2: bit indicator per layer l=1, …, v v=5-8: FFS	Pending
Inter-pol co-phase selection indicator for each layer	Part 2 Wideband or Subband (**)	v=1-4: - Alt1: QPSK with orthogonality constraints across v layers - Alt2: QPSK: 2-bit indicator per layer l=1,…,v v=5-8: FFS	Pending

(*): Not included when CQI reporting granularity is set to ‘wideband’

(**): Wideband when PMI reporting is set to ‘wideband’, Subband when PMI reporting granularity is set to ‘subband’

Agreement

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports with RI=5-8, decide, by RAN1#117, from the following schemes:

Scheme1: adding new (N1, N2) values for the Rel-15 Type-I RI=5-8
Scheme2:

W₁ structure: Independent selection of different ceil(v/2) SD basis vectors for RI = v, where each SD basis vector is applied to two respective layers except that, if v is odd, the last SD basis vector is applied to the orphan layer. Each of the SD basis vectors is freely selected from a group of N₁N₂ orthogonal SD DFT basis vectors via combinatorial indication

FFS: mapping between v layers and ceil(v/2) SD basis vectors
FFS: support of 4 selected SD basis vectors for RI=5-6

W₂ structure:

For inter-polarization co-phasing, M (e.g., M = 4) codepoints for the orphan layer and M/2 codepoints for two layers sharing a same SD basis vector;
A fixed  rotation of inter-polarization co-phasing between two layers sharing a same SD basis vector to achieve layer orthogonality.

Scheme3: the 1st beam is freely selected and subsequent 2 beams (RI=5-6) or 3 beams (RI=7-8) are freely selected such that they are orthogonal in at least one dimension (horizontal or vertical). Layers are mapped to the selected SD basis vectors following legacy Rel-15 for RI=5-8. One co-phasing across all layers ∈{1,j} following legacy Rel-15 Type-I RI=5-8.
Scheme4: concatenate two independently calculated RI=1-4 PMIs for RI=5-8 to reduce UE complexity where each PMI is calculated from the agreed RI=1-4 codebook (Scheme-A or Scheme-B) and the CQI for each of the two CWs is derived assuming it is received by one antenna group of 4 antenna ports (FFS: Whether additional mapping between the two PMIs and the two UE antenna groups is needed).
Other schemes are not precluded.

Agreement

For the Rel-19 Type-II codebook refinement for 48, 64, and 128 CSI-RS ports, except for Parameter Combination 8 from Rel-17 FeType-II PS, all legacy Parameter Combinations from Rel-16 eType-II (regular), Rel-18 Type-II Doppler (regular), and Rel-17 FeType-II PS are supported.

Agreement

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports, regarding CBSR design:

1-bit hard restriction is supported (analogous to Rel-15 Type-I)
FFS: 3-bit scaling factor for soft restriction with the scaling factor taken into account in CQI/PMI calculation
Moving (N₁, N₂) configuration out from CBSR IE and the CBSR can be optional configured

Send LS to RAN2, and subject to RAN2 consent

-bit CBSR where each bit in the CBSR is associated with a set of X₁X₂ SD basis vectors, where the set includes X₁ adjacent SD basis vectors along the N₁ direction and/or X₂ adjacent SD bases along the N₂ direction

FFS: Value(s) of X₁ and X₂ and detailed design/spec impact

FFS: Whether/how to enable shared CBSR in RRC configuration for Type-I/II codebooks with a same (N₁,N₂).

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, on the configured K_S>1 NZP CSI-RS resources, Pcoffset and PcoffsetSS are CSI-RS-resource-specific (i.e. configured independently across resources).

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, for M>1, SD basis selection is independently signalled per CRI (per CSI-RS resource).

Thursday

R1-2403649 DRAFT LS to RAN2 on CBSR for Rel-19 MIMO Samsung

Decision: Draft LS in 3649 is endorsed. Final LS is approved in R1-2403650.

R1-2403642 Moderator Summary for Thursday OFFLINE session on Rel-19 CSI enhancements Moderator (Samsung)

R1-2403641 Moderator Summary#4 on Rel-19 CSI enhancements: ROUND 4 Moderator (Samsung)

From Thursday session

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, in addition to reporting one type of CJT calibration report in one report, at least support reporting {(D_n,offset, d_n), n=0, 1, …, N_TRP – 1, n≠nref1} and {FO_n , n=0, 1, …, N_TRP – 1, n≠nref2} in one report

nref1 and nref2 are independently selected and indicated by the UE
One-part UCI is used

Agreement

For a UE indicated with two TCI states, regarding QCL assumptions for PDSCH, support the following QCL assumption for PDSCH:

Scheme E: The PDSCH DMRS port(s) are QCLed with the DL-RS associated with the first TCI state with respect to QCL-TypeA and QCLed with the DL-RS in the second TCI state with respect to QCL-TypeA except for {Doppler shift, average delay}

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports,

When M>1, the M PMIs are independently calculated and indicated
with the Rel-16 eType-II codebook and K_S={1,2,3,4}, support M=2 with a maximum of 16 ports per resource, R=1 only, and a maximum UCI payload of 1706 bits.

The value of M={1, 2} is NW-configured via higher-layer (RRC) signalling
The maximum value of M is subject to UE capability

on the configured K_S>1 NZP CSI-RS resources, reuse the legacy IMR rule for the Rel-15 CRI-based reporting for NZP CSI-RS resource for interference measurement, i.e. only 1 NZP CSI-RS resource for interference measurement can be configured

Conclusion

For the Rel-19 Type-I and Type-II codebook refinement for 48, 64, and 128 CSI-RS ports, for a given massive TXRU/antenna array, there is no consensus on the need for specification support for cell-specific precoder(s) for many-to-one mapping (virtualization) from multiple TXRUs to each CSI-RS port to facilitate full usage of all TXRUs for a pre-Rel-19 UE (i.e. cell-specific beamformed CSI-RS for pre-Rel-19 UEs).

Conclusion

For the Rel-19 Type-I and Type-II codebook refinement for 48, 64, and 128 CSI-RS ports, regarding the mapping from CSI-RS resource index/port index per resource and port index to CSI/PMI calculation, there is no consensus on supporting mapping method#3 (for K=4, 2x2 aggregation).

9.2.3 Support for 3-antenna-port codebook-based transmissions

R1-2402019 On codebook for 3-antenna-port UL transmission Huawei, HiSilicon

R1-2402065 Discussion on 3-antenna-port codebook-based transmissions ZTE

R1-2402081 Rel-19 CB-based UL for 3TX UE InterDigital, Inc.

R1-2402100 Discussion on 3-antenna-port codebook-based transmissions Spreadtrum Communications

R1-2402140 Support for 3Tx UL MIMO Intel Corporation

R1-2402157 Support for 3-antenna-port codebook-based transmissions MediaTek Inc.

R1-2402179 Support for 3-antenna-port codebook-based transmissions TCL

R1-2402237 Discussion on 3-antenna-port codebook-based uplink transmissions vivo

R1-2402282 Uplink 3 Port Codebook based Transmission Google

R1-2402323 Discussion on 3-antenna-port codebook-based transmissions OPPO

R1-2402378 Discussion on support for 3-antenna-port codebook-based transmissions CATT

R1-2402461 Views on Rel-19 3-antenna-port codebook-based transmissions Samsung

R1-2402498 Support for 3-antenna-port codebook-based transmissions Lenovo

R1-2402530 Discussion on 3-antenna-port codebook-based transmissions Langbo

R1-2402560 Discussion on support for 3-antenna-port codebook-based transmissions CMCC

R1-2402634 Discussions on 3-antenna-port codebook-based transmissions LG Electronics

R1-2402661 Discussion on the support of 3-antenna-port CB based transmissions Xiaomi

R1-2402685 Discussion on 3-antenna-port codebook-based transmissions Transsion Holdings

R1-2402723 Discussion on the 3-port codebook-based transmission Honor

R1-2402768 Discussion on 3-antenna-port codebook-based transmissions NEC

R1-2402793 Discussion on uplink enhancement for UE with 3Tx Fujitsu

R1-2402840 On the support for 3-antenna-port codebook-based transmissions Nokia

R1-2402876 Views on R19 3Tx codebook based transmission Apple

R1-2403099 Support for 3 Tx UL transmissions Ericsson

R1-2403110 Support for 3-antenna-port codebook-based transmission Sharp

R1-2403189 3 Tx UL MIMO transmissions Qualcomm Incorporated

R1-2403239 Discussion on support for 3-antenna-port codebook-based transmissions NTT DOCOMO, INC.

R1-2402083 FL Summary Support for 3TX CB-based Uplink; Preparatory Moderator (InterDigital, Inc.)

From Monday session

Agreement

To support codebook-based UL transmission by a 3TX UE, the agreed rank1 precoders in RAN1#116 can also be used when transform precoding is enabled (DFT-s-OFDM ).

Agreement

To indicate precoding information for codebook-based UL transmission by a 3TX UE,

Reuse legacy TPMI indication framework where TPMI and TRI are jointly indicated
TPMI field is 2 or 3bits for 3-antenna-port transmission

For maxRank equals to 1, TPMI field is 2 bits for DFT-s-OFDM and CP-OFDM
For maxRank equals to 2 or 3, TPMI field is 3 bits for CP-OFDM

Agreement

For SRS configuration supporting codebook-based UL transmission by a 3TX UE, support Alt1,

Alt1: Support configuration of X 4-port SRS resources in a resource set where one the ports is muted

FFS muting mechanism

where X can be up to 2, subject to UE capability.

R1-2402084 FL Summary Support for 3TX CB-based Uplink; First Round Moderator (InterDigital, Inc.)

From Tuesday session

Agreement

For codebook-based UL transmission by a 3TX UE, when 2 PTRS ports are configured by maxNrofPorts in PTRS-UplinkConfig, PTRS-DMRS association indication is as follows:

Value of MSB	DMRS port	~~Value of LSB~~	~~DMRS port~~
0	1st DMRS port which shares PTRS port 0	0	~~1st DMRS port which shares PTRS port 1~~
1	2nd DMRS port which shares PTRS port 0	1	~~2nd DMRS port which shares PTRS port 1~~

· Note: PUSCH antenna port 1000 and 1002 in indicated TPMI(s) share PT_RS port 0, and PUSCH antenna port 1001 is associated with PT_RS port 1

· Number of bits used for the indication:

o 1 bit

Agreement

For a 3TX UE, to support 3-port SRS transmission with reusing a 4-port SRS resource, support the following for muting one of the ports of the configured 4-port SRS resource.

· Option 3: Always a same port is muted, e.g., the 4^th port.

Agreement

For a 3TX UE, to support 3-port SRS transmission with reusing a 4-port SRS resource, UE splits a linear SRS power equally across the 3 unmuted antenna ports of the 4-port SRS resource.

Agreement

For 3-port codebook-based PUSCH transmission for a 3TX UE, scale factor s should be the ratio of the number of antenna ports with a non-zero PUSCH transmission power to 3 (except for full-power Mode 0).

· FFS: Whether specification needs to be updated to reflect the above.

R1-2402085 FL Summary Support for 3TX CB-based Uplink; Second Round Moderator (InterDigital, Inc.)

From Wednesday session

Agreement

For codebook-based UL transmission by a 3TX UE, when 1 PTRS port is configured by maxNrofPorts in PTRS-UplinkConfig, PTRS-DMRS association indication is as follows:

· Alt2: 2-bit indication

PTRS-DMRS association when 1 PT-RS port is configured

Value	DMRS port
0	1^st scheduled DMRS port
1	2^nd scheduled DMRS port
2	3^rd scheduled DMRS port
3	~~4^th scheduled DMRS port~~ Reserved

Agreement

For a 3TX UE, support Rel-17 M-TRP PUSCH repetition where,

· Two SRS resource sets, each with up to 2 of 4-port SRS resources are configured,

Note: The configured 4 port SRS resources are used to enable 3-port SRS transmission.

R1-2402086 Recommended Direction on 3TX CB-based Uplink in RAN1#117 Moderator (InterDigital, Inc.)

9.2.44 Enhancement for asymmetric DL sTRP/UL mTRP scenarios

R1-2402020 Discussion on power control enhancements for DL sTRP and UL mTRP deployment Huawei, HiSilicon

R1-2402066 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios ZTE, China Telecom

R1-2402070 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Ericsson

R1-2402082 Rel-19 Asymmetric mTRP Operation InterDigital, Inc.

R1-2402101 Enhancements for asymmetric DL sTRP/UL mTRP scenarios Spreadtrum Communications

R1-2402141 Enhancements for asymmetric DL/UL scenarios Intel Corporation

R1-2402158 Enhancement for asymmetric DL sTRP/UL mTRP scenarios MediaTek Inc.

R1-2402238 Discussion on asymmetric DL sTRP/UL mTRP scenarios vivo

R1-2402288 Discussion on asymmetric DL sTRP/UL mTRP scenarios TCL

R1-2402324 Enhancements on asymmetric DL sTRP/UL mTRP scenarios OPPO

R1-2402379 Discussion on asymmetric DL sTRP/UL mTRP scenarios CATT

R1-2402462 Views on Rel-19 asymmetric DL sTRP/UL mTRP scenarios Samsung

R1-2402499 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Lenovo

R1-2402507 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios China Telecom, ZTE

R1-2402531 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios Langbo

R1-2402561 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios CMCC

R1-2402635 Discussions on asymmetric DL sTRP/UL mTRP scenarios LG Electronics

R1-2402662 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios Xiaomi

R1-2402686 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios Transsion Holdings

R1-2402719 Discussion on asymmetric DL sTRP and UL mTRP ASUSTeK

R1-2402724 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios Honor

R1-2402759 Discussion on enhancements for asymmetric DL sTRP and UL mTRP scenarios NEC

R1-2402794 Discussion on UL-only mTRP operation Fujitsu

R1-2402841 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Nokia

R1-2402877 Views on R19 enhancement for asymmetric DL sTRP/UL mTRP Apple

R1-2402963 Considerations on enhancement for asymmetric DL sTRP/UL mTRP scenarios Sony

R1-2403016 Discussion on asymmetric DL_UL mTRP operation ETRI

R1-2403089 Discussion on enhancement for asymmetric DL sTRP and UL mTRP scenarios Google

R1-2403111 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Sharp

R1-2403132 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Panasonic

R1-2403190 Enhancement for asymmetric DL sTRP and UL mTRP deployment scenarios Qualcomm Incorporated

R1-2403240 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios NTT DOCOMO, INC.

R1-2403414 Summary #1 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

From Monday session

Agreement

For a UE configured with two SRS CLPC adjustment states, support Alt2 for indicating one of the SRS CLPC adjustment states to SRS:

Alt2: When the parameter srs-PowerControlAdjustmentStates is set to 'separateClosedLoop', closedLoopIndex-r17 for SRS in the TCI state indicates one of the SRS CLPC adjustment states

The candidate value of i0 and i1 in closedLoopIndex-r17 for SRS refers to the first and the second CLPC adjustment state separate from PUSCH, respectively.

Ericsson raised concerns on Alt2 due to potential issues with beam management.

Agreement

For indicating TPC command for those two SRS CLPC adjustment states through DCI when the UE is configured with two SRS CLPC adjustment states, support Option3:

· Option 3: enhance the legacy DCI format 2_3 of higher layer parameter srs-TPC-PDCCH-Group = typeA and typeB,

Agreement

For enhancing DCI format 2_3 for indicating TPC command for two SRS CLPC adjustment states, support Alt2:

Alt2: Introduce one 1-bit closed-loop-indicator field for each TPC command in DCI format 2_3

This 1-bit closed-loop-indicator indicates the first SRS CLPC adjustment state or the second SRS CLPC adjustment state.

Note: this 1-bit indicator is present for the CC where two SRS CLPC adjustment states are configured.

Agreement

For FR1, a joint TCI state can be associated with a PL offset.

When a joint TCI state associated with a PL offset is applied for the PUSCH/PUCCH/SRS transmission, the UE shall calculate the Tx power of the PUSCH/PUCCH/SRS based on the DL PL RS and PL offset associated with this joint TCI state.

Reuse the legacy uplink power control formulation by replacing legacy PL with a PL which is derived from the DL PL RS and the PL offset.
FFS: The UE can update UL PL in a way that new UL PL = current UL PL + an update delta indicated by the NW.

R1-2403415 Summary #2 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

From Tuesday session

Agreement

Support applying PL offset on PDCCH-order PRACH towards a UL TRP in FR1.

Note: The DL reference timing determination for PDCCH-order PRACH transmission to an UL TRP is still based on the DL RS defined in current RAN4 specification.
Above is subject to a separate UE capability signaling.

Agreement

Consider and down-select one from the following alts for indicating a PL offset for PDCCH-order PRACH transmission at least for FR1.

Alt1: RRC configures multiple PL offset values in PRACH-Config and PDCCH-order DCI indicates one of them through one DCI field.
Alt2: PDCCH order DCI indicates one PL offset value
Alt3: The PL offset associated with one of the indicated joint/UL TCI state for UL TRP in unified TCI framework is applied on the PDCCH-order PRACH transmission
Alt4: The PDCCH order DCI indicates one TCI state associated with a PL offset and the associated PL offset is applied on the PRACH transmission.
Alt5: RRC configures one PL offset value for PRACH and the PDCCH order DCI indicates whether this PL offset value is applied on PRACH transmission or not.

Note: Other alternatives are not precluded.

R1-2403416 Summary #3 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

From Wednesday session

Agreement

For the association between PL offset and joint/UL TCI state, consider and down-select one from the following Alts:

Alt1a: One PL offset value is configured in a joint or UL TCI state by RRC only
Alt1b: One PL offset value is configured in a joint or UL TCI state by RRC. A MAC CE can update the PL offset value(s) for joint or UL TCI state(s).
Alt2a: A list of PL offset configurations is configured by RRC in BWP/CC and each PL offset configuration contains one PL offset value. One new RRC parameter is introduced in a joint or UL TCI state to indicate one of the configured PL offset configurations.
Alt2b: A list of PL offset configurations is configured by RRC in BWP/CC and each PL offset configuration contains one PL offset value. One new RRC parameter is introduced in a joint or UL TCI state to indicate one of the configured PL offset configurations. A MAC CE can update the association between a joint or UL TCI state and PL offset configuration
Alt3: A list of PL offset configurations is configured by RRC in BWP/CC and each PL offset configuration contains one PL offset value. A MAC CE can activate/indicate one PL offset configuration for each activated joint or UL TCI state. In each joint or UL TCI state, the initial PL offset value is 0dB.
Alt4: A list of PL offset values is provided in a joint or UL TCI state by RRC. Each PL offset value is applied to a corresponding measured PL range.

Other alternatives are not precluded.

Agreement

For the asymmetric DL sTRP/UL mTRP deployment scenarios, study whether and how to indicate TPC command for SRS CLPC adjustment states through DCI format 1_1 and/or 0_1 when the UE is configured two SRS CLPC adjustment states.

RAN1#117

9.2 NR MIMO Phase 5

Please refer to RP-240087 for detailed scope of the WI.

[117-R19-MIMO] – Eko (Samsung)

Email discussion on Rel-19 MIMO Phase 5

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

9.2.1 Enhancements for UE-initiated/event-driven beam management

R1-2403846 Discussion on Rel-19 UE/Event-Driven Beam Management InterDigital, Inc.

R1-2403872 Enhancements for UE-initiated/event-driven beam management FUTUREWEI

R1-2403877 Discussion on Rel-19 Enhancement for UE-initiated/event-driven beam management New H3C Technologies Co., Ltd.

R1-2403900 Enhancements for UE-initiated/event-driven beam management MediaTek Inc.

R1-2403944 On UE initiated/event-driven beam management Huawei, HiSilicon

R1-2403985 Enhancements for event driven beam management Intel Corporation

R1-2404019 Discussion on UE-initiated/event-driven beam management Spreadtrum Communications

R1-2404106 Views on Rel-19 UE-initiated/event-driven beam management Samsung

R1-2404170 Discussion on UE-initiated/event-driven beam management vivo

R1-2404239 Discussion on enhancements for UE-initiated/event-driven beam management ZTE

R1-2404277 Enhancements for UE-initiated beam management Apple

R1-2404336 Enhancements for UE-initiated/event-driven beam management Lenovo

R1-2404394 Views on UE-initiated/event-driven beam management CATT

R1-2404449 Discussion on enhancements for UE-initiated/event-driven beam management CMCC

R1-2404475 Enhancements for UE-initiated/Event-Driven Beam Management Panasonic

R1-2404494 Discussion on UE initiated beam management Sony

R1-2404550 UE-initiated beam management LG Electronics

R1-2404574 Discussion on UE-initiated/event-driven beam management HONOR

R1-2404587 Discussion on enhancements for UE-initiated/event-driven beam management Fujitsu

R1-2404611 Enhancements for UE-initiated/event-driven beam management Xiaomi

R1-2404657 Discussion on enhancements for UE-initiated or event-driven beam management NEC

R1-2404739 Discussion on enhancements for UE-initiated/event-driven beam management Hyundai Motor Company

R1-2404746 Enhancements for UE-initiated beam management Ericsson

R1-2404770 Enhancements for UE-initiated/event-driven beam management ETRI

R1-2404813 Enhancements for UE-initiated/event-driven beam management Transsion Holdings

R1-2404882 Discussions on UE-initiated/event-driven beam management OPPO

R1-2404918 Enhancements to facilitate UE-initiated/event-driven beam management Nokia

R1-2404970 Enhancements for UE-initiated/event-driven beam management Sharp

R1-2405035 Discussion on enhancements for UE-initiated/event-driven beam management NTT DOCOMO, INC.

R1-2405111 Discussion on UE-initiated/event-driven beam management ITRI

R1-2405122 Discussions on enhancements for UE-initiated/event-driven beam management Ruijie Networks Co. Ltd

R1-2405148 UE-initiated/event-driven beam management Qualcomm Incorporated

R1-2405187 Discussion on UE initiated beam management ASUSTeK

R1-2405205 Enhancements for UE-initiated/event-driven beam management NICT

R1-2405238 Enhancements for UE-initiated/event-driven beam management CEWiT

R1-2405258 Discussions on enhancements for UE-initiated/event-driven beam management KDDI Corporation

R1-2405271 Discussion on enhancements for UE-initiated or event-driven beam management Google

R1-2404712 Offline summary for Rel-19 MIMO UEIBM (9.2.1) pre-RAN1#117 Moderator (ZTE)

R1-2404713 Moderator Summary #1 on UE-initiated/event-driven beam management Moderator (ZTE)

From Monday session

Agreement

On UE-initiated/event-driven beam reporting, regarding UL signaling content(s) of L1-RSRP report depending on Event-2, in a report instance, at least Option-3 is supported

Option-3: N ≥ 1 beam(s) are reported in the report instance,

At least one of N reported beam(s) should satisfy the condition of Event-2
N is configured by gNB

FFS: candidate value of ‘N’.

FFS: RRC can enable or disable whether current beam is always reported in addition to the N beams

FFS: Option-1/1a/1b/2.
Above applies at least for the single CC case

R1-2404714 Moderator Summary #2 on UE-initiated/event-driven beam management Moderator (ZTE)

From Tuesday session

Working Assumption

On beam report transmission procedure for UE-initiated/event-driven beam reporting

For mode-A, at least support one-bit indication in the first PUCCH channel to request a resource for a second UL channel to carry beam report.

In such case, a periodic PUCCH resource (with PUCCH format 0/1) is configured by dedicated RRC signaling.

For mode-B, at least support one-bit indication in the first PUCCH channel to notify a second UL channel to carry beam report.

In such case, a periodic PUCCH resource (with PUCCH format 0/1) is configured by dedicated RRC signaling.

FFS: Whether/how to support multi-bit indication in the first PUCCH for mode-A and mode-B, e.g., when multi-event(s) are approved.
FFS: details on the dedicated RRC signaling
Above applies at least for the single CC case.

Agreement

Regarding RS measurement for the current beam for Event 2, for Option-2a, support the both schemes as follows.

Scheme-1: RS for current beam is the QCL RS in the indicated TCI state

FFS: Whether/How to handle the case if only one TRS is configured in the indicated TCI state.

Scheme-2: the RS for current beam is the SSB which is QCLed with the QCL RS in the indicated TCI state.
Enabling one of either Scheme-1 or Scheme-2 is selected by NW.

FFS: The above selection is via an explicit RRC parameter or an implicit manner, e.g., if the RS(s) for new beam are CSI-RS, Scheme-1 is enabled; otherwise, Scheme-2 is enabled.
(Working Assumption) Enabling of either Scheme-1 or Scheme-2 should ensure the same RS type for RS measurement for current beam and new beam.

The above QCL RS is the RS w.r.t. QCL-TypeD, if there are two QCL RSs in the indicated TCI state.

Agreement

Regarding RS measurement for the new beam for Event 2, at least Option-3a is supported

Option-3a (explicit manner): The RS(s) for new beam(s) are explicitly configured
FFS: Option-3b/3c

Option-3b: The RS(s) for new beam(s) are implicitly derived from QCL RS(s) of activated TCI state(s).
Option-3c: The RS(s) for new beam(s) are implicitly derived from QCL RS(s) of TCI state(s) in a configured subset of the legacy RRC-configured TCI state list

R1-2404715 Moderator Summary #3 on UE-initiated/event-driven beam management Moderator (ZTE)

From Wednesday session

Agreement

On UE-initiated/event-driven beam reporting, regarding L1-RSRP report format Option-3 depending on Event-2, for a report instance where N ≥ 1 beam(s) are reported, the following is supported.

· RRC can enable or disable whether current beam is always reported

o When enabled by RRC, the current beam + N beams from the measurement RSs for new beam(s) are reported

§ Note: The reported current beam is NOT counted in the N reported beams.

o When disabled by RRC, N beams are reported.

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Mode-A, the DCI format in Step-2 comprises UL-grant DCI format, and the second channel in Step-3 is at least PUSCH.

The UL-grant DCI format at least comprises DCI format 0_1/0_2.

FFS: DCI format 0_3

FFS: How to trigger the UEI beam report by the UL-grant DCI format
FFS: the DCI format in Step-2 comprises DL-grant DCI format, and the second channel in Step-3 is PUCCH.

1-bit field in the DL-grant DCI format is introduced to indicate the transmission of the UEI beam report

The PUCCH resource for HARQ-ACK transmission can be reused to carry both the HARQ-ACK and UEI beam report.

The DL-grant DCI format at least comprises DCI format 1_1/1_2.

FFS: DCI format 1_3

R1-2405638 Moderator Summary #4 on UE-initiated/event-driven beam management Moderator (ZTE)

From Thursday session

Agreement

Regarding the triggering event determination for Event 2:

If within a time window (which is configurable), the number of Event-2 instance(s) for at least one same new beam is greater than or equal to a configurable number M, UE initiated beam report occurs.

Note: Event-2 instance for a new beam is determined if the L1-RSRP of the new beam becomes a threshold value better than the current beam

Above feature is subject to UE capability.

· Basic feature: Once the L1-RSRP of the new beam becomes a threshold value better than the current beam, UE initiated beam report occurs

FFS: Whether the above is captured in RAN1 or RAN2 specification.

Agreement

On UE-initiated/event-driven beam reporting, regarding trigger events, the following Event-1 and 7a/7b, are provided for down-selection or combination in RAN1#118 (possible outcome is that no new event is supported)

· Event-1: Quality of the current beam is worse than a certain threshold.

· Event-7a: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the worst quality.

· Event-7b: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the best quality.

Agreement

Regarding explicit RS configuration for new beam measurement for Event 2, down-select the following options in the RAN1#118:

· Option-1: The RS(s) for new beam(s) are explicitly configured in one RS resource set associated with an CSI reporting configuration;

o FFS: The RS in the RS resource set can be updated by MAC-CE.

· Option-2: A list of RS(s) for new beam measurement can be configured by RRC, and a subset can be activated for new beam measurement by MAC-CE.

o FFS: If a list size is small, MAC-CE activation is not needed

· Option-3: A list of RS resource (s) for new beam measurement can be configured by RRC, and a subset of RS resource(s) in the list can be provided for new beam measurement by indicated TCI state.

· Others are not precluded.

· FFS: Each RS for new beam measurement should be associated with a configured joint/DL TCI state which can be used as the indicated TCI state

Agreement

Regarding RS measurement for the current beam for Event 2, for Option-2a, besides for scheme-1 and scheme-2, further study the following for handling the case that only one TRS is configured in the indicated TCI state.

· Option-1: Introducing additional scheme: the RS for current beam can be a CSI-RS for beam management derived from the QCL RS in the indicated TCI state;

· Option-2: Further support TRS as measurement RS of current beam for determining L1-RSRP

· Option-3: Introducing additional scheme: The RS for current beam is explicitly configured by RRC or MAC-CE (Option-2C in RAN1 116b agreement).

· Option-4: No further enhancement (i.e., in such case, Scheme-2 is used)

· Others are not precluded.

9.2.2 CSI enhancements

Including support for up to 128 CSI-RS ports on FR1 and UE reporting enhancement for CJT

R1-2403847 Discussion on Rel-19 Enhancements of CSI InterDigital, Inc.

R1-2403876 Discussion on Rel-19 CSI enhancements New H3C Technologies Co., Ltd.

R1-2403884 CSI enhancement for NR MIMO Phase 5 Tejas Networks Limited

R1-2405340 CSI enhancements to support up to 128 CSI-RS ports MediaTek Inc. (rev of R1-2403901)

R1-2405445 On 128 CSI-RS ports and UE reporting enhancement Huawei, HiSilicon (rev of R1-2403945)

R1-2403981 CSI enhancements for MIMO Intel Corporation

R1-2404004 Discussion on Rel-19 CSI enhancements TCL

R1-2404020 Discussion on CSI enhancements Spreadtrum Communications

R1-2405382 Views on Rel-19 CSI enhancements Samsung (rev of R1-2405365; rev of R1-2404109)

R1-2404171 Discussion on Rel-19 CSI enhancements vivo

R1-2404240 Discussion on CSI enhancements ZTE

R1-2404278 Views on R19 MIMO CSI enhancement Apple

R1-2404337 Discussion on CSI enhancements Lenovo

R1-2404395 Views on MIMO CSI enhancements in Rel-19 CATT

R1-2404450 Discussion on CSI enhancements CMCC

R1-2404495 Additional views on CSI enhancements Sony

R1-2404551 Discussions on CSI enhancements LG Electronics

R1-2404575 Discussion on CSI enhancements HONOR

R1-2404588 Discussion on Rel-19 CSI enhancements Fujitsu

R1-2404612 Discussion on CSI enhancement Xiaomi

R1-2404668 Discussion on CSI enhancements NEC

R1-2404687 CSI Enhancement for NR MIMO Google

R1-2404883 CSI enhancements for Rel-19 MIMO OPPO

R1-2404919 CSI enhancement for NR MIMO Phase 5 Nokia

R1-2404923 CSI enhancements for Rel.19 MIMO Fraunhofer IIS, Fraunhofer HHI

R1-2404971 CSI enhancements Sharp

R1-2405005 CSI enhancements for large antenna arrays and CJT Ericsson

R1-2405036 Discussion on CSI enhancements NTT DOCOMO, INC.

R1-2405149 CSI enhancements for >32 ports and UE-assisted CJT Qualcomm Incorporated

R1-2405206 CSI enhancements NICT

R1-2405239 CSI Enhancements CEWiT

R1-2405255 Discussion on CSI enhancements for NR MIMO Phase 5 KDDI Corporation

R1-2404107 Moderator summary for OFFLINE discussion on Rel-19 CSI enhancements Moderator (Samsung)

R1-2404108 Moderator summary on Rel-19 CSI enhancements Moderator (Samsung)

From Monday session

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, regarding the dynamic range for delay offset reporting D_n,offset, i.e. A_D, at least support the following values: {0.5CP, CP}

· Decide, by RAN1#117, whether any of the following candidate values are supported: {0.75CP, 1.5CP, ,}

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, regarding the dynamic range for frequency offset reporting FO_n, i.e. A_FO, at least support the following values: {0.1ppm, 0.2ppm}

· Decide, by RAN1#117, whether any of the following candidate values are supported: {0.025ppm, 0.05ppm, 1/(8Dt), 1/(16Dt), 1/(32Dt)}

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset), =1 only (agreed in RAN1#116bis) implies that the measured/reported phase offsets {_n,, n=0, 1, …, N_TRP – 1, n≠nref} are associated with the entire configured CSI reporting band (i.e. ‘wideband’).

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset), decide, by RAN1#117, whether to also support S>1 (sub-band reporting) as follows:

A sub-band size is selected from {8,16} PRBs

FFS: Whether the sub-band size is NW-configured via higher-layer (RRC) signalling or selected (hence reported) by the UE.

Denoting the number of sub-bands within the configured CSI reporting band as N_SB-P, and the sub-bands are indexed as {0, 1, …, N_SB-P–1}, decide, by RAN1#117, from the following reporting options:

Opt1: {(F_n,₀, G_n), n=0, 1, …, N_TRP – 1, n≠nref}, where F_n,₀is the phase offset corresponding to sub-band 0 and the phase offset for sub-band s can be calculated as F_n,₀ + sG_n

, where {[32], [64], [128], [256]}

Opt2: S= N_SB-P, i.e. {(F_n,₀, F_n,_1,..._, F_NSB-P_-1), n=0, 1, …, N_TRP – 1, n≠nref}

The alphabet for F_n,_sfollows the previously agreed alphabet for S=1, including the ‘invalid’ state.
FFS: Whether restriction on the maximum payload size is needed.

Note: For all the above reporting options, the UE performs measurement over the entire configured CSI reporting band.

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset),

For a given phase offset reporting configuration, the UE can be configured (via higher-layer/RRC signaling) with Q associated SRS resource(s) for antenna switching

FFS: The supported value(s) of Q

The UE antenna port(s) for receiving the CSI-RS configured for phase offset measurement are same as the UE antenna port(s) for transmitting the selected/configured port(s) from the associated SRS resource(s)

For discussion purposes only (not necessarily for specification), the UE antenna port is referred to as the ‘reference UE antenna port’

Agreement (further modified as shown in red in Tuesday session)

For the Rel-19 aperiodic standalone CJT calibration reporting, regarding active resource counting and O_CPU, when ReportQuantity is ‘cjtc-Dd’ (Doffset+d) or cjtc-F’ (frequency offset), fully reuse those from Rel-18 TDCP reporting

· ~~For O_CPU, Y=N_TRP for each CJT calibration report type~~

· O_CPU =X.N_TRP where X≥1 is defined based on UE capabilities and determined by the UE for each CJT calibration report type

Agreement

For the Rel-19 Type-II codebook refinement for 48, 64, and 128 CSI-RS ports based on the Rel-18 Type-II Doppler codebook,

· Ordering the K_DOPPK CSI-RS resources ascendingly by the CSI-RS resource ID and k_DOPP ={0,1,…, K_DOPP –1}, CSI-RS resources { k_DOPPK, k_DOPPK +1, …, (k_DOPP+1)K –1} are associated with the k_DOPP-th CSI-RS resource group

· FFS: If the CSI-RS resources in a resource group span two consecutive slots, m is 2.

· FFS: If the CSI-RS resources in a resource group are located in one slot, m can be configured from {1, 2}

Agreement

For the Rel-19 Type-I and Type-II codebook refinement for 48, 64, and 128 CSI-RS ports, regarding aggregation of K NZP CSI-RS resources to attain 32 < P (or P_CSI-RS)≤ 128, support only the following combinations of K and P (or P_CSI-RS):

· For P (or P_CSI-RS) = 48, K = 2 (each resource 24 ports) and 3 (each resource 16 ports)

· For P (or P_CSI-RS) = 64, K = 2 (each resource 32 ports) and 4 (each resource 16 ports)

· For P (or P_CSI-RS) = 128, K = 4 (each resource 32 ports)

Agreement

For the Rel-19 Type-I and Type-II codebook refinement for 48, 64, and 128 CSI-RS ports, regarding port mapping,

· Following legacy principle, “sequential ordering/indexing within” a group of Q indices {i₀, i₁, …, i_Q-1} is a linearly increasing sequence such that i_q < i_q+1 (where q=0, 1, …, Q-2 is the port index within a CSI-RS resource, and i_q or i_q+1 {0, 1,…, KQ-1}) is the port index for the codebook, across the K>1 CSI-RS resources).

· After resource aggregation, P (=48, 64, or 128) ports are numbered in accordance to Table 7.4.1.5.3-1 from TS 38.211.

Agreement

For the Rel-19 Type-I codebook refinement for 48, 64, and 128 CSI-RS ports, for RI=v=1, support the following:

for each group of SD basis vectors, a 3-bit scaling factor can be NW-configured via higher-layer (RRC) signalling, where the scaling factors are defined as scalings on the power control offset configured for the associated CSI-RS resources

The values of and for this feature are separately configured from those for CBSR
Separate configuration (RRC signalling) from CBSR
The candidate values of and are the same as those agreed for CBSR

The codepoints of each of the group-specific 3-bit scaling factors are mapped to values of
Note: This feature is a separate UE capability

FFS: Whether this can be extended to RI=v>1 as well as Type-II codebook refinement.

Agreement

For the Rel-19 Type-I SP and Type-II codebook refinement for 48, 64, and 128 CSI-RS ports, on CBSR, the value of X₁ and X₂) are separately NW-configured via higher-layer (RRC) signalling from {1, 2, 4, [8, 16]}

· FFS: Dependence on each supported (X₁, X₂) value on the configured (N₁, N₂) value

Agreement

For the Rel-19 Type-I SP and Type-II codebook refinements (except based on Rel-18 Type-II Doppler) for 48, 64, and 128 CSI-RS ports, regarding CPU occupation

For Capability 1 timeline: O_CPU = ceil(P/32)
For Capability 2 timeline: O_CPU= 1

Agreement

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports, regarding UCI omission, fully reuse the legacy rules for Rel-15 Type-I SP codebook.

Agreement

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports, regarding UCI parameters for Scheme-B RI=v=1-4:

· SD basis vector selection indicator for each layer is in Part 2 (wideband) and bits per layer l=1, …, v

· Inter-pol co-phase selection indicator for each layer is in Part 2 (wideband or subband) and 2 bits (representing {+1, +j, -1, -j}) per layer l=1,…,v

Agreement

For the Rel-19 Type-I single-panel (SP) codebook refinement for 48, 64, and 128 CSI-RS ports, for Scheme-A RI=3-4 only, the legacy mapping of i_1,3 to (k₁,k₂) for (N₁=3,N₂=2) from Table 5.2.2.2.1-4 of TS 38.214 is used for all of the newly supported (N₁,N₂) values.

· FFS: whether the i_1,3 table (Table 5.2.2.2.1-4 of TS 38.214) needs to be further extended.

Agreement

On the NZP CSI-RS resource aggregation of K=2, 3 or 4 legacy NZP CSI-RS resources to attain a total of 48, 64, and 128 ports (for Rel-19 Type-I/II codebook refinement), support to configure a CSI-RS resource set with the K CSI-RS resources as the associated NZP CSI-RS for each of the SRS resource set(s) with higher layer parameter usage in SRS-ResourceSet set to 'nonCodebook',

· The previously agreed restrictions on the K resources for Rel-19 Type-I/II codebook refinement apply.

· Reuse the legacy approach for triggering of the NZP-CSI-RS resources and the legacy timeline for the NZP-CSI-RS resources and SRS.

Agreement

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports with RI=5-8, support the following schemes:

The same O₁=O₂ value(s) as RI=1-4 are supported
Scheme-A (based on Scheme3 described in RAN1#116bis):

W₁ structure:

The 1st SD basis vector is freely selected and subsequent 2 (RI=5-6) or 3 SD basis vectors (RI=7-8) are freely selected such that they are orthogonal in at least one dimension (horizontal or vertical).
The v layers are mapped to the selected SD basis vectors following legacy Rel-15 Type-I for RI=5-8.

W₂ structure:

Following legacy Rel-15 Type-I RI=5-8

Scheme-B (based on Scheme2 described in RAN1#116bis):

W₁ structure:

Independent selection of different ceil(v/2) SD basis vectors for RI = v, where each SD basis vector is applied to two respective layers following legacy Rel-15 Type-I for RI=5-8, except that, if v is odd, the last SD basis vector is applied to the orphan layer.

FFS: mapping between the orphan layer and its selected SD basis vector and, if needed, UE reporting of the selection
FFS: support of 4 selected SD basis vectors for RI=5-6

The SD basis vectors are freely selected from a group of N₁N₂ orthogonal SD DFT basis vectors via combinatorial indication, as well as a layer-common (q₁,q₂)

W₂ structure:

For the orphan layer, the inter-polarization co-phasing is selected from {1, j, -1, -j}
For two layers sharing a same SD basis vector, the inter-polarization co-phasing between two layers is selected from the following pairs {(1, -1), (j, -j)} to achieve inter-layer orthogonality.

Only Scheme-A (RI=1-4+RI=5-8) and Scheme-B (RI=1-4+RI=5-8) are supported in Rel-19

Proposal 1.A.2:

For a UE configured with a total of P_SRS=6 or 8 ports across ≥1 SRS resources for antenna switching intended for xT6R or xT8R, respectively, support the following fixed SRS port grouping where (with the P_SRS ports indexed in an ascending order according to SRS resource ID and port number within each SRS resource):

SRS port group 0, corresponding to CW0, comprises the first P_SRS/2 out of P_SRS ports; and
SRS port group 1, corresponding to CW1, comprises the second P_SRS/2 out of P_SRS ports

No other spec enhancement is introduced, e.g. new CW-to-layer mapping, DL resource allocation, DCI format

Note: The above grouping assumption is to align NW and UE on the association between SRS ports and reported CQIs for the two CWs when reportQuantity = ‘cri-RI-CQI’.

Note: different SRS ports are associated with different UE antenna ports.

Note: if one single CW is scheduled, both SRS port groups can correspond to the same CW

Note: This feature is a separate UE capability and, for UEs supporting this capability, configured via RRC (FFS details on the extend of RRC configuration)

Companies are encouraged to evaluate for further discussion in RAN1#118.

R1-2405487 Moderator summary of Tuesday morning offline on Rel-19 CSI enhancements Moderator (Samsung)

R1-2405484 Moderator Summary#2 on Rel-19 CSI enhancements: Round 2 Moderator (Samsung)

From Tuesday session

Conclusion

For the Rel-19 Type-I single-panel (SP) codebook refinement for 48, 64, and 128 CSI-RS ports, there is no consensus on additionally supporting O₁=O₂=2.

Agreement

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports, on CBSR, the following (X₁, X₂) values are supported: (1,1), (2,1), (2,2), (4,1), (4,2), (4,4),

· FFS: (1,2), (1,4), (2,4)

Agreement

For the 3-bit scaling scheme for Type-I codebook, the following (X₁, X₂) values are supported: (2,1), (2,2), (4,1), (4,2), (4,4),

FFS: (1,2), (1,4), (2,4), (8,1)

Conclusion

For the Rel-19 Type-I codebook refinement for 48, 64, and 128 CSI-RS ports, on the agreed 3-bit group-based scaling factor for RI=v=1, there is no consensus on supporting this feature for codebooks other than for Rel-19 Type-I SP codebook refinement.

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, for M>1, support the following:

· Resource-specific RI, i.e. RI is independently calculated and indicated for each of the selected M NZP CSI-RS resources

o FFS: If resource-common RI indication is also supported

· 4-bit wideband CQIs are independently calculated and reported for each of the M selected NZP CSI-RS resources

· 2-bit differential SB CQIs are independently calculated and reported for each of the M selected NZP CSI-RS resource

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, for M=2, when Rel-16 eType-II codebook is configured, FD basis selection and indication are resource-specific (per resource).

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, for M=2, when Rel-16 eType-II codebook is configured, RRC configuration of Parameter Combination is resource-common.

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports:

· Active resource counting = K_S (following legacy)

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, the UCI parameters are captured in the tables below:

· FFS: Mapping order

· FFS: Whether it is possible not to report d_n

When ReportQuantity is ‘cjtc-Dd’ (Doffset+d)

Parameter	Details/description
nref	Reference TRS resource set index, based on the ordering from RRC configuration: bits
{D_n,offset, n=0, 1, …, N_TRP – 1, n≠nref }	Delay offset for CSI-RS resource n: bits
{d_n, n=0, 1, …, N_TRP – 1, n≠nref }	1-bit inside/outside indicator for CSI-RS resource n: bits

When ReportQuantity is ‘cjtc-F’ (frequency offset)

Parameter

Details/description

nref

Reference TRS resource set index, based on the ordering from RRC configuration: bits

{FO_n ,

n=0, 1, …, N_TRP –1, n≠nref}

Frequency offset for CSI-RS resource n:

bits

When ReportQuantity is ‘cjtc-Dd-F’ (joint Doffset+d and FO)

Parameter	Details/description
nref1	Reference TRS resource set index for Doffset+d, based on the ordering from RRC configuration: bits
nref2	Reference TRS resource set index for FO, based on the ordering from RRC configuration: bits
{D_n,offset, n=0, 1, …, N_TRP – 1 n≠nref1}	Delay offset for CSI-RS resource n: bits
{d_n, n=0, 1, …, N_TRP – 1, n≠nref1 }	1-bit inside/outside indicator for CSI-RS resource n: bits
{FO_n , n=0, 1, …, N_TRP –1, n≠nref2}	Frequency offset for CSI-RS resource n: bits

Conclusion

For the Rel-19 aperiodic standalone CJT calibration reporting, regarding the ‘out of range’ or ‘invalid’ quantization state/hypothesis, there is no consensus on specifying a condition/event for such state.

R1-2405488 Moderator summary of Tuesday afternoon offline on Rel-19 CSI enhancements Moderator (Samsung)

R1-2405485 Moderator Summary#3 on Rel-19 CSI enhancements: Round 3 Moderator (Samsung)

From Wednesday session

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset),

Regarding the number of configured associated SRS resource(s) (=Q) for antenna switching xTyR, support at least Q=1 where:

the configured associated SRS resource is selected from all the y/x SRS resources and all the configured resource set(s)
FFS (by RAN1#118): whether Q>1 is also supported
FFS (by RAN1#118): the supported value(s) of x

Regarding how to determine the SRS port corresponding to the ‘reference UE antenna port’, support P_SRS =1 SRS port selected from all the ports from the configured Q associated SRS resource(s)

FFS (by RAN1#118): Whether P_SRS >1 is also supported

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, regarding timeline, fully reuse those from Rel-18 TDCP reporting.

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, regarding the applicable type(s) of the configured N_TRP NZP CSI-RS resources/resource sets when ReportQuantity is ‘cjtc-Dd’ (Doffset+d) or ‘cjtc-F’ (frequency offset), all the resources across the N_TRP TRS resource sets are configured with the same bandwidth.

Conclusion

Supporting CSI-RS for CSI

Agreement

· all the ‘CSI-RS for CSI’ resources within each resource set follow the legacy pre-Rel-19 rules of CSI-RS resources associated with a same resource set

· all the resources across the N_TRP CSI-RS resources/resource sets are configured with the same bandwidth.

Conclusion

For the Rel-19 aperiodic standalone CJT calibration reporting, regarding the applicable type(s) of the configured NTRP NZP CSI-RS resources/resource sets when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset), there is no consensus on:

Supporting multi-port CSI-RS for CSI.

Conclusion

For the Rel-19 Type-II codebook refinement for 48, 64, and 128 CSI-RS ports based on the Rel-18 Type-II Doppler codebook, there is no consensus on specifying further restriction on m values based on the slot location(s) of the CSI-RS resources in a resource group.

Agreement

For the Rel-19 Type-II codebook refinement for 48, 64, and 128 CSI-RS ports, on CBSR,

-bit group-based CBSR
the following (X₁, X₂) values are supported:

P	(N₁, N₂)	(X₁, X₂)
48	(8,3)	(1,1), (2,1), (4,1)
48	(6,4)	(1,1), (2,1), (2,2),
64	(16,2)	(1,1), (2,1), (2,2), (4,1), (4,2)
64	(8,4)	(1,1), (2,1), (2,2), (4,1), (4,2)
128	(16,4)	(1,1), (2,1), (2,2), (4,1), (4,2)
128	(8,8)	(1,1), (2,1), (2,2), (4,1), (4,2)

FFS: (1,2), (1,4), (2,4), when applicable

Conclusion

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, there is no consensus on supporting the following report quantities when Rel-15 Type-I SP codebook: ‘cri-RI-i1-CQI’, ‘cri-RI-i1’, ‘cri-RI-CQI’.

R1-2405678 Moderator summary of Thursday offline on Rel-19 CSI enhancements Moderator (Samsung)

R1-2405486 Moderator Summary#4 on Rel-19 CSI enhancements: Round 4 Moderator (Samsung)

From Thursday session

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, regarding the applicable type(s) of the configured N_TRP NZP CSI-RS resources when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset), one ‘CSI-RS for CSI’ resource set with N_TRP resources is supported

FFS: 1 CSI-RS resource set with JN_TRP single-port CSI-RS resources where J>1 is the number of CSI-RS resources per TRP
FFS: 1 or N_TRPTRS resource sets can also be used when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset)

Conclusion

For the Rel-19 aperiodic standalone CJT calibration reporting, regarding the applicable type(s) of the configured N_TRP NZP CSI-RS resources/resource sets when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset), there is no consensus on supporting any additional time separation between RSs beyond what’s already permissible by the use of TRS resource sets.

Conclusion

Any additional time separation between RSs beyond what’s already permissible by the use of TRS resource sets
Any restriction on the number of resources within each resource set
CSI-RS type(s) other than TRS can be used for joint reporting of Doffset+d and FO

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, when ReportQuantity is ‘cjtc-Dd-F’ (joint Doffset+d and FO)

· Fully reuse timeline and active resource counting from Rel-18 TDCP reporting.

· O_CPU = 2X.N_TRP where X≥1 is defined based on UE capabilities and determined by the UE for each CJT calibration report type.

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, for A-CSI only, the NW can configure M_R (<M) of K_S CSI-RS resources to be selected as part of reporting the M “quadruplets”:

(M–M_R) CRIs, each with bits are reported, along with the M sets of CQI/PMI/RI/(if applicable) LI
The value of M_R is NW-configured via higher-layer (RRC) signaling
The M_R selected resources are NW-configured via higher-layer (RRC) signaling
FFS: value of M_R
This is an optional UE capability

Agreement

For the Rel-19 Type-I multi-panel (MP) codebook refinement for 48, 64, and 128 CSI-RS ports, for RI=1-4, support the following (compromise between Scheme1 and Scheme2 described in RAN1#116bis):

W₁ structure: Independent SD basis selection across all the Ng=K NZP CSI-RS resources, reusing legacy Rel-15 Type-I Pcsi-rs<16 SP SD basis selection rules with L=1 for RI=1-4

Ng = K = {2, 4} denotes the number of NZP CSI-RS resources associated with the Ng panels

W₂ structure:

Legacy Rel-15 Type-I inter-polarization co-phasing rules independently in each resource,
Layer-common wideband inter-resource QPSK co-phasing independently reported for resource n = 2,…,K with respect to the first resource.

Rel-19 Type-I MP does not support RI=5-8.

Reuse Rel-15 Type-I MP legacy designs for UCI omission, and CBSR.

For CSI calculation, reuse Rel-18 Type II CJT CSI-RS port ordering for UE assumption on the transmitted PDSCH symbols across antenna ports.

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, regarding CBSR and RI restriction, down-select (by RAN1#118) one from the following alternatives:

Alt1. K_S per-resource CBSRs and K_S per-resource RI restrictions
Alt2. (legacy CRI-based) Resource-common CBSR and resource-common RI restriction
Alt3. K_S per-resource CBSRs and resource-common RI restriction

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset), if S>1 (sub-band reporting) is supported, select one from option 1 and option 2, by RAN1#118, from the following:

A sub-band size is selected from {8,16} PRBs

The sub-band size is NW-configured via higher-layer (RRC) signalling

Denoting the number of sub-bands within the configured CSI reporting band as N_SB-P, and the sub-bands are indexed as {0, 1, …, N_SB-P–1}, decide, by RAN1#118, from the following reporting options:

Opt1: {(F_n,₀, G_n), n=0, 1, …, N_TRP – 1, n≠nref}, where F_n,₀is the phase offset corresponding to sub-band 0 and the phase offset for sub-band s can be calculated as F_n,₀ + sG_n

, where ={64, 128}

Opt2: S= N_SB-P, i.e. {(F_n,₀, F_n,_1,..._, F_n,NSB-P_-1), n=0, 1, …, N_TRP – 1, n≠nref}

The alphabet for F_n,_sfollows the previously agreed alphabet for S=1, including the ‘invalid’ state
The maximum N_SB-P is [4]

FFS: For all the above reporting options, the UE performs measurement over the entire configured CSI reporting band

FFS: Further restriction on CSI-RS (e.g. RE density)

Note: Companies to report whether their evaluation is based on precoded or non-precoded CSI-RS.

9.2.3 Support for 3-antenna-port codebook-based transmissions

R1-2403848 Discussion on Rel-19 CB-based UL for 3TX UE InterDigital, Inc.

R1-2403902 Support for 3-antenna-port codebook-based transmissions MediaTek Inc.

R1-2403946 On codebook for 3-antenna-port UL transmission Huawei, HiSilicon

R1-2403983 Support for 3Tx UL MIMO Intel Corporation

R1-2404021 Discussion on 3-antenna-port codebook-based transmissions Spreadtrum Communications

R1-2404046 Discussion on Rel-19 CB-based UL transmission for 3TX UE TCL

R1-2404110 Views on Rel-19 3-antenna-port codebook-based transmissions Samsung

R1-2404172 Discussion on 3-antenna-port codebook-based uplink transmissions vivo

R1-2404241 Discussion on 3-antenna-port codebook-based transmissions ZTE

R1-2404279 Views on R19 3Tx codebook based transmission Apple

R1-2404338 Support for 3-antenna-port codebook-based transmissions Lenovo

R1-2404396 Views on support for 3-antenna-port codebook-based transmissions CATT

R1-2404451 Discussion on support for 3-antenna-port codebook-based transmissions CMCC

R1-2404552 Discussions on 3-antenna-port codebook-based transmissions LG Electronics

R1-2404589 Discussion on uplink enhancement for UE with 3Tx Fujitsu

R1-2404613 Discussion on the support of 3-antenna-port CB based transmissions Xiaomi

R1-2404669 Discussion on 3-antenna-port codebook-based transmissions NEC

R1-2404688 Uplink 3 Port Codebook based Transmission Google

R1-2404814 Discussion on 3-antenna-port codebook-based transmissions Transsion Holdings

R1-2404884 Discussion on 3-antenna-port codebook-based transmissions OPPO

R1-2404920 On the support for 3-antenna-port codebook-based transmissions Nokia

R1-2404972 Support for 3-antenna-port codebook-based transmission Sharp

R1-2405037 Discussion on support for 3-antenna-port codebook-based transmissions NTT DOCOMO, INC.

R1-2405119 Support for 3 Tx UL transmissions Ericsson

R1-2405150 3 Tx UL MIMO transmissions Qualcomm Incorporated

R1-2403850 Summary of Offline Discussions on 3TX CB-based Uplink Moderator (InterDigital, Inc.)

R1-2403851 FL Summary Support for 3TX CB-based Uplink; First Round Moderator (InterDigital, Inc.)

From Monday session

Agreement

· Update the agreement made in RAN1 #116bis as the following.

Agreement

For a 3TX UE, to support 3-port SRS transmission with reusing a 4-port SRS resource, support the following for muting one of the ports of the configured 4-port SRS resource,

Option 3: Always a same port is muted, ~~e.g.,~~ i.e., the 4th port

Agreement

For codebook-based M-TRP PUSCH repetition by a 3TX UE, scheduled by DCI format 0_1/0_2,

· Reuse Rel-17 M-TRP PUSCH repetition design, where the second precoding information field only indicates TPMI index, and applies same rank as indicated by the first precoding information field.

Agreement

For codebook-based M-TRP PUSCH repetition by a 3TX UE, scheduled by DCI format 0_1/0_2,

Introduce new tables as Table I, II, III for the second precoding information field, for maxRank=1 or 2 or 3, respectively.

Table I: Second precoding information for 3 antenna ports if maxRank=1

Bit field	codebookSubset=NonCoherent
0	1 layer: TPMI=0
1	1 layer: TPMI=1
2	1 layer: TPMI=2
3	Reserved

o Table II: Second precoding information for 3 antenna ports if maxRank=2

Bit field	codebookSubset=NonCoherent
0	1 layer: TPMI=0
1	1 layer: TPMI=1
2	1 layer: TPMI=2
3	1 layer: Reserved
0	2 layer: TPMI=0
1	2 layer: TPMI=1
2	2 layer: TPMI=2
3	2 layer: Reserved

o Table III: Second precoding information for 3 antenna ports if maxRank=3

Bit field	codebookSubset=NonCoherent
0	1 layer: TPMI=0
1	1 layer: TPMI=1
2	1 layer: TPMI=2
3	1 layer: Reserved
0	2 layer: TPMI=0
1	2 layer: TPMI=1
2	2 layer: TPMI=2
3	2 layer: Reserved
0	3 layer: TPMI=0
1~3	3 layer: reserved

Agreement

For codebook-based M-TRP PUSCH repetition by a 3TX UE, for indication of PTRS-DMRS association,

When 1 PTRS port is configured by maxNrofPorts in PTRS-UplinkConfig, reuse Rel-17 multi-TRP TDM repetition,
When 2 PTRS ports are configured by maxNrofPorts in PTRS-UplinkConfig, and maxRank = 2 or 3,

A second PTRS-DMRS association field (1 bit) is used to indicate the association between PTRS ports and DMRS ports for the 2nd SRS resource set (i.e.,2nd TRP).

Agreement

For codebook-based UL transmission by a 3TX UE, subject to its capability,

A 3TX UE may report a maximum number of 3 layers
A 3TX UE may report a maximum number of SRS ports of up to 3

Note: SRS resource definition is not changed nor the number of SRS ports in the SRS resource.

R1-2403852 FL Summary Support for 3TX CB-based Uplink; Second Round Moderator (InterDigital, Inc.)

Presented in Wednesday session.

R1-2403853 Recommended Direction on 3TX CB-based Uplink in RAN1#118 Moderator (InterDigital, Inc.)

9.2.44 Enhancement for asymmetric DL sTRP/UL mTRP scenarios

R1-2403849 Discussion on Rel-19 Asymmetric mTRP Operation InterDigital, Inc.

R1-2403903 Enhancement for asymmetric DL sTRP/UL mTRP scenarios MediaTek Inc.

R1-2403947 Enhancements for asymmetric DL sTRP/UL mTRP scenarios Huawei, HiSilicon

R1-2403984 Enhancements for asymmetric DL/UL scenarios Intel Corporation

R1-2404022 Enhancements for asymmetric DL sTRP/UL mTRP scenarios Spreadtrum Communications

R1-2404111 Views on Rel-19 asymmetric DL sTRP/UL mTRP scenarios Samsung

R1-2404173 Discussion on asymmetric DL sTRP/UL mTRP scenarios vivo

R1-2404242 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios ZTE, China Telecom

R1-2404280 Enhancements for asymmetric DL sTRP/UL mTRP Apple

R1-2404339 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Lenovo

R1-2404397 Views on asymmetric DL sTRP/UL mTRP scenarios CATT

R1-2404424 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios China Telecom, ZTE

R1-2404452 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios CMCC

R1-2404476 Enhancement for Asymmetric DL sTRP/UL mTRP Scenarios Panasonic

R1-2404496 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Sony

R1-2404532 Enhancement for asymmetric DL sTRP UL mTRP scenarios Ericsson

R1-2404553 Discussions on asymmetric DL sTRP/UL mTRP scenarios LG Electronics

R1-2404568 Discussion on asymmetric DL sTRP/UL mTRP scenarios TCL

R1-2404590 Discussion on UL-only mTRP operation Fujitsu

R1-2404614 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios Xiaomi

R1-2404658 Discussion on enhancements for asymmetric DL sTRP and UL mTRP scenarios NEC

R1-2404771 Discussion on asymmetric DL sTRP and UL mTRP operation ETRI

R1-2404815 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios Transsion Holdings

R1-2404885 Enhancements on asymmetric DL sTRP/UL mTRP scenarios OPPO

R1-2404921 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Nokia

R1-2404973 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Sharp

R1-2405038 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios NTT DOCOMO, INC.

R1-2405151 Enhancement for asymmetric DL sTRP and UL mTRP deployment scenarios Qualcomm Incorporated

R1-2405188 Discussion on asymmetric DL sTRP and UL mTRP ASUSTeK

R1-2405272 Discussion on enhancement for asymmetric DL sTRP and UL mTRP scenarios Google

R1-2405346 Summary #1 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

From Tuesday session

Proposal 3.1:

To fulfil the asymmetric DL sTRP/UL mTRP deployment scenarios, support two TAs for single DCI based multi-TRP/panel and single TRP.

Reuse Rel-18 specification of two TA for multi-DCI based multi-TRP/panel and remove the restriction that coresetPoolIndex needs to be configured.

Companies are encouraged to consider above for further discussion in RAN1#118.

Agreement

For indicating a PL offset for PDCCH-order PRACH transmission at least for FR1, further study and down-select one from the Alt1 and Alt3 by RAN1#118 meeting:

Alt1: RRC configures multiple PL offset values [in PRACH-Config] and PDCCH-order DCI indicates one of them through one DCI field
Alt3: The PL offset associated with one of the indicated joint/UL TCI state for UL TRP in unified TCI framework is applied on the PDCCH-order PRACH transmission
FFS: the details of DCI field design.

Agreement

In Rel-19, the value range of starting bit of block in DCI format 2-3 is extended from 1~31 to 1~X.

FFS the value of X>31

FFS: Condition under which the above is applicable.

Agreement

Introduce a new RRC parameter per BWP/CC to indicate that two separate SRS CLPC adjustment states are configured for SRS in a BWP/CC.

Agreement

For the association between PL offset and joint/UL TCI state, support the following

Alt1b: One PL offset value is configured in a joint or UL TCI state by RRC, where different PL offset values can be configured to different joint or UL TCI states. A MAC CE can update the PL offset value(s) for joint or UL TCI state(s).

Conclusion

There is no consensus on the following proposal:

Proposal 1.6: Support to update a UL PL for a joint/UL TCI state as follows:

· When this joint/UL TCI state is activated and it is not in the current active TCI state list, a UL PL is calculated as: UL PL = PL estimated from DL PL RS – the value of PL offset.

· When this joint/UL TCI state is activated and it is in the current active TCI state list, the UE updates the UL PL as: new UL PL = current UL PL + the updated delta indicated by the NW.

R1-2405347 Summary #2 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

From Thursday session

Agreement

For the asymmetric DL sTRP/UL mTRP scenarios, study and decide the value range and candidate values of PL offset value.

Agreement

For the asymmetric DL sTRP/UL mTRP scenarios, study whether/how to consider PL offset in PHR calculation, including Type 1 PHR based on actual PUSCH transmission, Type 1 PHR based on reference PUSCH, Type 3 PHR based on actual SRS and Type 3 PHR based on reference SRS.

Conclusion

For the asymmetric DL sTRP/UL mTRP deployment scenario, reuse the rel-17 unified TCI/ICBM and rel-18 unified TCI framework:

When rel-17 unified TCI/ICBM is configured:

For FR1: one joint TCI state or {one DL TCI state + one UL TCI state} can be applied.
For FR2: {one DL TCI state + one UL TCI state} can be applied.

When rel-18 unified TCI is configured:

For FR1: up to two joint TCI states or {one DL TCI state + up to two UL TCI state} can be applied.
For FR2: {one DL TCI state + up to two UL TCI states} can be applied.

Final summary in R1-2405348.

RAN1#118

9.2 NR MIMO Phase 5

Please refer to RP-240087 for detailed scope of the WI.

[118-R19-MIMO] – Eko (Samsung)

Email discussion on Rel-19 MIMO Phase 5

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2406648 List of RRC and MAC CE impact for Rel-19 MIMO Ph5 Samsung

From Thursday session

R1-2407284 DRAFT LS to RAN2 on RRC and MAC CE impacts for Rel-19 NR MIMO Ph5 Moderator (Samsung)

Decision: The draft LS to RAN2 is endorsed. Final LS is approved in R1-2407285.

9.2.1 Enhancements for UE-initiated/event-driven beam management

R1-2405814 Enhancements for UE-initiated/event-driven beam management FUTUREWEI

R1-2405870 On UE initiated/event-driven beam management Huawei, HiSilicon

R1-2405875 On Rel-19 UE/Event-Driven Beam Management InterDigital, Inc.

R1-2405887 Enhancements for UE-initiated/event-driven beam management MediaTek Inc.

R1-2405903 Discussion on UE-initiated/event-driven beam management Spreadtrum Communications

R1-2405980 Discussion on enhancements for UE-initiated/event-driven beam management CMCC

R1-2406027 Enhancements for event driven beam management Intel Corporation

R1-2406028 Discussion on enhancements for UE-initiated/event-driven beam management ZTE Corporation, Sanechips

R1-2406043 Offline summary for Rel-19 MIMO UEIBM (9.2.1) pre-RAN1#118 Moderator (ZTE)

R1-2406177 Discussion on UE-initiated/event-driven beam management vivo

R1-2406260 Discussions on UE-initiated/event-driven beam management OPPO

R1-2406279 Enhancements for UE-initiated/event-driven beam management Xiaomi

R1-2406310 Discussion on enhancements for UE-initiated/event-driven beam management Fujitsu

R1-2406363 On UE-initiated/event-driven beam management CATT

R1-2406420 UE-initiated beam management LG Electronics

R1-2406454 Enhancements for UE-initiated/Event-Driven Beam Management Panasonic

R1-2406467 Enhancements for UE-initiated/event-driven beam management Sony

R1-2406521 Enhancements for UE-initiated/event-driven beam management Lenovo

R1-2406531 Discussion on UE-initiated/event-driven beam management TCL

R1-2406543 Discussion on enhancements for UE-initiated or event-driven beam management NEC

R1-2406574 Discussion on enhancements for UE-initiated/event-driven beam management Hyundai Motor Company

R1-2406576 Discussion on UE-initiated/event-driven beam management HONOR

R1-2406595 Discussions on enhancements for UE-initiated/event-driven beam management Ruijie Networks Co. Ltd

R1-2406642 Views on Rel-19 UE-initiated/event-driven beam management Samsung

R1-2406682 Discussions on enhancements for UE-initiated/event-driven beam management KDDI Corporation

R1-2406700 Enhancements for UE-initiated/event-driven beam management Transsion Holdings

R1-2406722 Enhancements for UE-initiated/event-driven beam management ETRI

R1-2406745 Enhancements to facilitate UE-initiated/event-driven beam management Nokia

R1-2406831 Enhancements for UE-initiated beam management Apple

R1-2406887 Enhancements for UE Initiated Beam Management Meta Ireland

R1-2406925 Discussion on enhancements for UE-initiated/event-driven beam management NTT DOCOMO, INC.

R1-2407002 Enhancements for UE-initiated/event-driven beam management Sharp

R1-2407024 UE-initiated/event-driven beam management Qualcomm Incorporated

R1-2407066 Discussion on UE-initiated/event-driven beam management ITRI

R1-2407075 Enhancements for UE-initiated/event-driven beam management CEWiT

R1-2407111 Discussion on enhancements for UE-initiated or event-driven beam management Google

R1-2407122 Discussion on UE initiated beam report ASUSTeK

R1-2407143 Enhancements for UE-initiated/event-driven beam management NICT

R1-2407145 Enhancements for UE-initiated beam management Ericsson

R1-2406044 Moderator Summary #1 on UE-initiated/event-driven beam management Moderator (ZTE)

From Monday session

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, for regarding Mode-B, the pre-configured resource(s) for the second channel in Step-2 is at least type 1 CG-PUSCH.

· FFS: PUCCH as the second channel

· FFS: Whether the PUSCH can be with UL data

Agreement

Regarding explicit RS configuration for new beam measurement for Event 2, at least Option-1 is supported

· Option-1: The RS(s) for new beam(s) are explicitly configured in one RS resource set associated with an CSI reporting configuration

o If legacy UE capability signaling cannot be reused, introduce a UE capability signaling of indicating the maximum number of the configured RS(s) in the RS resource set.

o FFS: The RS in the RS resource set can be updated by MAC-CE

Agreement

On UE-initiated/event-driven beam reporting, regarding L1-RSRP report format Option-3 depending on Event-2, the following differential L1-RSRP report format is supported.

CRI or SSBRI #1

CRI or SSBRI #2

…

CRI or SSBRI #N

L1-RSRP #1

Differential L1-RSRP #2

…

Differential L1-RSRP #N

Differential L1-RSRP for current beam, if report mode that current beam is always reported is enabled by RRC

Note: Other contents are not precluded

· Differential L1-RSRP #2~#N/current beam is determined based on the difference between measured L1-RSRP corresponding to the CRI/SSBRI #2~#N/current beam and the measured L1-RSRP corresponding to CRI/SSBRI #1

o L1-RSRP#1 is the largest measured RSRP among reported ones, and an absolute L1-RSRP.

o FFS: range and step size of differential L1-RSRP

· FFS: Whether/how to report additional indication of which CRI/SSBRI(s) satisfy the condition of Event-2.

· FFS: Additional report content(s) (e.g., reporting configuration ID, indication for synchronization state, event ID, or cell ID).

R1-2406045 Moderator Summary #2 on UE-initiated/event-driven beam management Moderator (ZTE)

From Tuesday session

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the dedicated RRC signaling for first PUCCH channel configuration for Mode-A, down-select one of the following

Alt-1 (dedicated SR for mode-A): Introduce RRC parameter, e.g., reportResourceRequest-UEIBR, corresponding to the one-bit indication in the first PUCCH channel

The RRC parameter is associated with the dedicated SchedulingRequestId.

Note: The detailed signaling is up to RAN2.

Alt 2 (new UCI type): Introduce RRC parameter, e.g., firstPUCCHResourceConfig-ModeA-UEIBR, for the periodic PUCCH resource configuration.

Note: The RRC parameter is NOT associated with SchedulingRequestId.
FFS: how to encode 1-bit to PUCCH resource, e.g., reuse encoding mechanism of positive/negative SR.
The dedicated RRC parameter at least comprises the following:

periodicityAndOffset
PUCCH-ResourceID

Above applies at least for the single CC case.

Agreement

Alt 1 (dedicated SR for mode-B): Introduce RRC parameter, e.g., reportNotification-UEIBR, corresponding to the one-bit indication in the first PUCCH channel

The RRC parameter is associated with the dedicated SchedulingRequestId.

Note: The detailed signaling is up to RAN2.

Alt 2 (new UCI type): Introduce RRC parameter, e.g., firstPUCCHResourceConfig-ModeB-UEIBR, for the periodic PUCCH resource configuration.

Note: The RRC parameter is NOT associated with SchedulingRequestId.
FFS: how to encode 1-bit to PUCCH resource, e.g., reuse encoding mechanism of positive/negative SR.
The dedicated RRC parameter at least comprises the following:

periodicityAndOffset
PUCCH-ResourceID

Above is at least applied to a single CC case.

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the triggering procedure in Step-2 of Mode-A, select one of the following options

· Option-1: Introduce a new 1-bit field in DCI format 0_1/0_2 to trigger the transmission of the UEI beam report

o FFS: DCI format 0_3

· Option-2: Reuse CSI request field in DCI format 0_1/0_2 to trigger the transmission of the UEI beam report

o FFS: DCI format 0_3

· FFS: Whether/how to handle the case that multiple CSI report configuration(s) for the UE-initiated/event-driven beam report are associated with the same first PUCCH resource and/or the same scheduled PUSCH

Comeback on Thursday for down-selection: agreement stays as is.

Conclusion

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Mode-A, there is no RAN1 consensus on additionally supporting that the DCI format in Step-2 comprises DL-grant DCI format, and the second channel in Step-3 is PUCCH.

R1-2406046 Moderator Summary #3 on UE-initiated/event-driven beam management Moderator (ZTE)

From Wednesday session

Agreement

On UE-initiated/event-driven beam reporting, regarding L1-RSRP report format Option-3 depending on Event-2, the candidate value of ‘N’ at least comprises {1, 2, 3, 4}

FFS: additional candidate value(s) of {5, 6, 7, 8}
FFS: If ‘N’ is not RRC configured, only one L1-RSRP and CRI/SSBRI are reported by default.

Agreement

Regarding RS measurement for the current beam for Event 2, for Option-2a, besides for scheme-1 and scheme-2, further down-select one of the following for handling the case that only one TRS is configured in the indicated TCI state in RAN1#118bis

Option-1: Introducing additional scheme: the RS for current beam can be a CSI-RS for beam management derived from the QCL RS in the indicated TCI state;
Option-2: Further support TRS as measurement RS of current beam for determining L1-RSRP
Option-3: Introducing additional scheme: The RS for current beam is explicitly configured by RRC or MAC-CE (Option-2C in RAN1 116b agreement).
Option-4: No further enhancement.

Note: If there is no consensus in RAN1 on one of Options 1/2/3, Option 4 will be taken.

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, for the case the pre-configured Type-1 CG PUSCH carry the beam report, for the second UL channel in Mode-B, at least one or both of the following should be supported:

· Option-1: The same Type-1 CG PUSCH can carry UL-SCH and the beam report.

· Option-2: The Type-1 CG PUSCH is a dedicated type-1 CG PUSCH for carrying the beam report.

o Note: This PUSCH can NOT carry UL-SCH. This PUSCH can NOT carry any other UCI.

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Mode-B, UEI beam report is carried on a first available transmission occasion of the second UL channel X symbols after sending the last symbol of report notification on the first PUCCH channel.

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding resource mapping/configuration between first and second channel in Mode-B, for a given CSI report configuration, the following is provided for down-selection.

· Option-1 (one-to-one): Only one first PUCCH resource and only one pre-configured resource for second UL channel can be associated with the CSI report configuration for UE-initiated/event-driven beam reporting.

Option-1A: Same periodicity between first PUCCH resource and pre-configured resource for second UL channel.
Option-1B: No restriction in terms of periodicity.

· Option-2 (one-to-M): Only one first PUCCH resource and one or more pre-configured resource(s) for second UL channel can be associated with CSI report configuration for UE-initiated/event-driven beam reporting.

R1-2407470 Moderator Summary #4 on UE-initiated/event-driven beam management Moderator (ZTE)

From Thursday session

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Event-2, for at least Mode-B, the beam report should be carried in the second UL channel in the CC where the corresponding CSI report configuration is configured.

· Above applies to both cross-CC and same-CC beam report.

· Note: Above is applied to the case that second UL channel is PUSCH.

· FFS: Whether the first and second channels can be from the same/different CC.

Working Assumption

On UE-initiated/event-driven beam reporting, regarding trigger events, besides for Event-2, Event-1 and Event-7 are both supported.

Event-1: Quality of the current beam is worse than a certain threshold.
Event-7: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the M-th best quality.

M is RRC configured with subjective to UE capability signalling

UE may only indicate a single candidate value or not support Event-7.

The additionally supported events will reuse the same design as event 2 – unless there is consensus to do otherwise
The additionally supported events will be lower priority compared to event 2.

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Mode-A and/or Mode-B, further study the following for first PUCCH transmission

UCI multiplexing/dropping/prioritization rule
Conditions for the transmission of the first PUCCH.

Whether the PUCCH resource in the first PUCCH channel can be associated with multiple CSI report configurations for UE-initiated/event-driven beam reporting from one or multiple CC(s).

Whether/how to re-transmit the first PUCCH channel.

Whether/how to apply prohibit-timer or maximum number of (re)transmission(s) for first PUCCH channel.

9.2.2 CSI enhancements

Including support for up to 128 CSI-RS ports on FR1 and UE reporting enhancement for CJT

R1-2405871 On 128 CSI-RS ports and UE reporting enhancement Huawei, HiSilicon

R1-2405876 On Rel-19 Enhancements of CSI InterDigital, Inc.

R1-2405888 CSI enhancements to support up to 128 CSI-RS ports MediaTek Inc.

R1-2405904 Discussion on CSI enhancements Spreadtrum Communications

R1-2405936 CSI enhancements Tejas Networks Limited

R1-2405943 CSI enhancements for Rel. 19 MIMO Fraunhofer IIS, Fraunhofer HHI

R1-2405955 CSI Enhancement for NR MIMO Google

R1-2405981 Discussion on CSI enhancements CMCC

R1-2406024 CSI enhancements for MIMO Intel Corporation

R1-2406029 Discussion on CSI enhancements ZTE Corporation, Sanechips

R1-2406178 Discussion on Rel-19 CSI enhancements vivo

R1-2406261 CSI enhancements for Rel-19 MIMO OPPO

R1-2406280 Views on CSI enhancement Xiaomi

R1-2406311 Discussion on Rel-19 CSI enhancements Fujitsu

R1-2406364 Views on Rel-19 MIMO CSI enhancements CATT

R1-2406431 CSI enhancements TCL

R1-2406468 More views on CSI enhancements Sony

R1-2406522 Discussion on CSI enhancements Lenovo

R1-2406548 Discussion on CSI enhancements NEC

R1-2406577 Discussion on CSI enhancements HONOR

R1-2406643 Moderator summary for OFFLINE discussion on Rel-19 CSI enhancements Moderator (Samsung)

R1-2407262 Views on Rel-19 CSI enhancements Samsung (rev of R1-2406645)

R1-2406723 Discussion on Rel-19 CSI enhancements ETRI

R1-2406746 CSI enhancement for NR MIMO Phase 5 Nokia

R1-2406832 Views on R19 MIMO CSI enhancement Apple

R1-2407308 CSI enhancements for large antenna arrays and CJT Ericsson (rev of R1-2406907)

R1-2406926 Discussion on CSI enhancements NTT DOCOMO, INC., NTT CORPORATION

R1-2407003 CSI enhancements Sharp

R1-2407184 CSI enhancements for >32 ports and UE-assisted CJT Qualcomm Incorporated (rev of R1-2407025)

R1-2407074 CSI Enhancements CEWiT

R1-2407126 Discussion on CSI enhancements for NR MIMO Phase 5 KDDI Corporation

R1-2407144 CSI enhancements NICT

R1-2406644 Moderator summary on Rel-19 CSI enhancements Moderator (Samsung)

From Monday session

Conclusion:

For the Rel-19 aperiodic standalone CJT calibration reporting, when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset), regarding the number of configured associated SRS resource(s) (=Q) for antenna switching xTyR and the number of SRS ports (=P_SRS) corresponding to the ‘reference UE antenna port’, there is no consensus to support the following:

Q>1
P_SRS >1

Note: This implies no support for configuring >1 SRS resource sets for associated SRS when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset).

Note: There is a source R1-2407184 showing performance benefit of using multiple UE antenna ports non-coherent with each other.

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset),

The supported value(s) of x follows the supported configuration(s) of SRS resource for antenna switching xTyR used for reciprocity-based DL CSI acquisition

Note: This doesn’t have any spec impact (no new RRC parameter is needed)

For the selection of P_SRS=1 SRS port corresponding to the ‘reference UE antenna port’ (out of the available port(s)), decide, by RAN1#118, from the following schemes:

Scheme1: NW-configured via higher-layer (RRC) signalling
Scheme1B: NW dynamic selection via MAC CE or A-CSI triggering (DCI)
Scheme2: UE-selected, the selection included in the phase offset report
Scheme3: Fixed rule, e.g. the first out of the available port(s)

FFS:

· Whether/how to identify the transmission occasion of the Q=1 associated SRS resource to determine the reference UE antenna port in relation to the CSI request and/or SRS triggering

· The supported time-domain behaviour(s) for the associated SRS resource (periodic, semi-persistent, aperiodic)

o In case the NW configures the Q=1 associated SRS resource from an existing SP and/or AP SRS antenna switching resource configuration for DL CSI acquisition (which utilizes dynamic signalling), whether/how to identify the Q=1 associated SRS resource

Agreement

For the Rel-19 aperiodic standalone CJT calibration (CJTC) reporting, to facilitate UE-specific delay offset pre-compensation on PDSCH by the NW, decide, by RAN1#118, whether to support configuring a UE (via RRC signaling) to perform PMI calculation for the Rel-18 eType-II CJT CSI report assuming pre-compensation using the UE-reported delay offset (when ReportQuantity is ‘cjtc-Dd’). And if supported, whether any of the following is additionally supported or not:

NW indicates the delay offset value to be compensated for the Rel-18 eType-II CJT CSI report, and/or
The two separately configured reports (i.e. Rel-18 eType-II CJT CSI report and the CJTC delay offset report) are always jointly triggered and carried on a same PUSCH (hence on a same slot)
The delay offset value to be compensated is the latest reported DO before the DCI triggering the CJT CSI reporting

FFS: AP-CSI-RS can be configured for the Rel-18 eType-II CJT report.

The above only applies when the CMRs do not share common QCL source for average delay indication.

Agreement

For the Rel-19 aperiodic standalone CJT calibration (CJTC) reporting, to facilitate UE-specific frequency offset pre-compensation on PDSCH by the NW, decide, by RAN1#118, whether to support configuring a UE (via RRC signaling) to perform PMI calculation for the Rel-18 eType-II CJT CSI report assuming pre-compensation using the UE-reported frequency offset (when ReportQuantity is ‘cjtc-F’). And if supported, whether any of the following is additionally supported or not:

NW indicates the frequency offset value to be compensated for the Rel-18 eType-II CJT CSI report, and/or
The two separately configured reports (i.e. Rel-18 eType-II CJT CSI report and the CJTC frequency offset report) are always jointly triggered and carried on a same PUSCH (hence on a same slot)
The frequency offset value to be compensated is the latest reported fO before the DCI triggering the CJT CSI reporting

FFS: AP-CSI-RS can be configured for the Rel-18 eType-II CJT report.

The above only applies when the CMRs do not share common QCL source for Doppler shift indication.

Conclusion:

For the Rel-19 aperiodic standalone CJT calibration reporting, there is no consensus to support the following reporting formats:

Joint FO + wideband PO reporting
Joint Dd + FO + wideband PO reporting

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, regarding the resolution for frequency offset reporting FO_n, additionally support M_FO = 256.

Conclusion:

For the Rel-19 aperiodic standalone CJT calibration reporting, regarding the dynamic range for delay offset reporting D_n,offset and frequency offset reporting FO_n, there is no consensus on supporting additional values of dynamic range.

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, the UCI mapping order is as follows:

When ReportQuantity is ‘cjtc-Dd’ (Doffset+d):

nref,
{D_n,offset, n=0, 1, …, N_TRP – 1, n≠nref} ordered from the lowest to highest CSI-RS resource set ID,
{d_n, n=0, 1, …, N_TRP – 1, n≠nref} ordered from the lowest to highest CSI-RS resource set ID

When ReportQuantity is ‘cjtc-F’ (FO):

nref,
{FO_n, n=0, 1, …, N_TRP – 1, n≠nref} ordered from the lowest to highest CSI-RS resource set ID,

When ReportQuantity is ‘cjtc-Dd-F’ (joint Doffset+d and FO):

nref1,
nref2,
{D_n,offset, n=0, 1, …, N_TRP – 1, n≠nref} ordered from the lowest to highest CSI-RS resource set ID,
{d_n, n=0, 1, …, N_TRP – 1, n≠nref} ordered from the lowest to highest CSI-RS resource set ID
{FO_n, n=0, 1, …, N_TRP – 1, n≠nref} ordered from the lowest to highest CSI-RS resource set ID,

Agreement

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports with RI=5-8, regarding Scheme-B, reuse the legacy Rel-15 Type-I layer pairing scheme, and fixed mapping between SD basis vectors and layers:

The k-th SD basis vector is associated with the k-th layer-group.
Note: This should be the baseline based on joint SD basis selection/indication using the agreed combinatorial indication ( bits).

L_Gdenotes the number of layer groups per previous agreement.

Note: For RI=5-6, L_G=3 was agreed, and the additional support for L_G=4 is still FFS.

Agreement

For the Rel-19 Type-II codebook refinement based on Rel-18 Type-II Doppler for 48, 64, and 128 CSI-RS ports,

For Capability 1 timeline:

O_CPU is the legacy Rel-18 Type-II Doppler O_CPU multiplied by ceil(P/32) and replace K with K_DOPP for AP-CSI-RS, while still not exceeding 8
Active resource counting follows the legacy Rel-18 Type-II Doppler

For Capability 2 timeline:

O_CPUis the legacy Rel-18 Type-II Doppler O_CPUand replace K with K_DOPP for AP-CSI-RS
Active resource counting follows the legacy Rel-18 Type-II Doppler

Agreement

For the Rel-19 Type-I MP codebook refinements for 48, 64, and 128 CSI-RS ports, regarding O_CPU, timeline, active resource counting, and CMR restriction (FDM/TDM, EPRE offset), fully reuse those for the Rel-19 Type-I SP codebook.

Agreement

For the Rel-19 Type-I MP codebook refinement for 48, 64, and 128 CSI-RS ports, the UCI parameters are captured in the tables below:

· Note: The second column includes the location of the parameters when reported with two-part UCI.

Parameter	UCI	Details/description
RI	Part 1	Same as Rel-15 Type-I SP: RI=v={1,2,3,4}
Wideband CQI for the first TB	Part 1	Same as Rel-15 Type-I SP
Subband differential CQI for the first TB (*)	Part 1	Same as Rel-15 Type-I SP
First SD basis vector selection indicator	Part 2 Wideband	One indicator per each of the Ng resources: · Each of the Ng indicators is the same as Rel-15 Type-I SP with the scheme following < 16-port design of Rel-15 Type-I SP codebookMode=1
Second SD basis vector selection indicator	Part 2 Wideband	One indicator per each of the Ng resources: · Each of the Ng indicators is the same as Rel-15 Type-I SP with the scheme following < 16-port design of R15 Type-I SP codebookMode=1
Inter-pol co-phase selection indicator	Part 2 Wideband or Subband (**)	One (set of) indicator per each of the Ng resources: · Same as Rel-15 Type-I SP with the scheme following < 16-port design of R15 Type-I codebookMode=1
Inter-resource co-phasing	Part 2 Wideband	QPSK (2-bit) co-phasing on resource k=2,…,K relative to the first resource, layer-common

(*): Not included when CQI reporting granularity is set to ‘wideband’

(**): Wideband when PMI reporting is set to ‘wideband’, Subband when PMI reporting granularity is set to ‘subband’

Agreement

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports, the UCI parameters are captured in the tables below for Scheme-A for RI=5-8:

Note: The second column includes the location of the parameters when reported with two-part UCI

Scheme-A

Parameter	UCI	Details/description
First SD basis vector selection indicator	Part 2 Wideband	v=5-8: Decide (by RAN1#118) Alt1 vs Alt2 Alt1. Same as legacy Rel-15 Type-I SP, separate (i1, i2) indicators of bits and bits, respectively Alt2: Separate (i1, i2) indicators of bits and bits, respectively; and separate (q₁, q₂) indicators of bits and bits, respectively.
Second SD basis vector selection indicator	Part 2 Wideband	v=5-8: Freely select the other n_SDBV=2 (v=5-6) or 3 (v=7-8) SD basis vectors such that they are orthogonal in at least one dimension (horizontal or vertical). Decide (by RAN1#118) the indication scheme.
Inter-pol co-phase selection indicator	Part 2 Wideband or Subband (**)	v=5-8: Same as legacy Rel-15 Type-I SP

(*): Not included when CQI reporting granularity is set to ‘wideband’

(**): Wideband when PMI reporting is set to ‘wideband’, Subband when PMI reporting granularity is set to ‘subband’

Agreement

For the Rel-19 Type-I and Type-II codebook refinement for 48, 64, and 128 CSI-RS ports, regarding NZP CSI-RS resource aggregation to attain 32 < P (or PCSI-RS) ≤ 128, for AP-CSI-RS where the K NZP CSI-RS resources are located in two consecutive slots,

Except for codebook refinement based on Rel-18 Type-II Doppler, introduce per-resource higher-layer (RRC) configuration to indicate (via 1-bit per resource) whether 1-slot offset relative to the legacy resource-set-level slot offset configuration should be assumed or not.
For codebook refinement based on Rel-18 Type-II Doppler, introduce per-resource higher-layer (RRC) configuration to indicate (via 1-bit per resource) whether 1-slot offset relative to the resource group slot offset should be assumed or not.

Agreement

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports, regarding the port subset indication (from the Rel-18 SD NES Type-1), extend the bitmap (i.e., port-subsetIndicator) by adding p48, p64, and p128 along with their appropriate lengths

Note: Per previous agreements, K is the number of aggregated NZP CSI-RS resources to attain 32 < P (or P_CSI-RS) ≤ 128.

Agreement

For the Rel-19 Type-I multi-panel (MP) codebook refinement for 48, 64, and 128 CSI-RS ports, regarding the W₂ structure, clarify that:

Inter-polarization co-phasing is based on legacy Rel-15 Type-I SP codebookMode=1 for P_CSI-RS<16
QPSK inter-resource co-phasing alphabet is {+1,+j,-1,-j}

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, regarding UCI parameters when two-part UCI/CSI is used:

Part 1: M CRI(s), M RI(s), M sets of CQI values for 1st CW

When M_R is configured, the CRI(s) associated with the M_R resource(s) are not reported

Part 2: M sets of {PMI, LI (if applicable), CQI values for 2nd CW (if applicable)}

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, if M_Ris configured, the supported value(s) of M_Rare as follows:

Rel-15 Type-I SP: {1, 2}
Rel-16 eType-II: {1}

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, regarding CBSR and RI restriction, support resource-specific specific CBSR.

· FFS (by RAN1#118): Whether RI restriction is resource-common or resource-specific.

R1-2407282 Moderator Summary on Tuesday offline for Rel-19 CSI enhancements Moderator (Samsung)

R1-2407279 Moderator Summary#2 on Rel-19 CSI enhancements: Round 2 Moderator (Samsung)

From Tuesday session

Agreement

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports, regarding first SD basis vector selection indicator for Scheme-A for RI=5-8, reuse the legacy Rel-15 Type-I SP scheme, i.e. separate (i₁, i₂) indicators of bits and bits, respectively.

Agreement

At least for type 1 single panel, for the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, regarding UCI omission for the UCI reported in CSI part-2, other than priority 0 (G0), the UCI packing order and the 2M consecutive priority levels are defined w.r.t the M CRIs (including the non-reported M_R CRIs) as follows:

Consecutive priority levels (higher to lower):

Even sub-bands (G1) associated with the first configured CMR among the non-reported M_R CRIs,
Odd sub-bands (G2) associated with the first configured CMR among the non-reported M_R CRIs,
…,
Even sub-bands (G1) associated with the last configured CMR among the non-reported M_R CRIs,
Odd sub-bands (G2) associated with the last configured CMR among the non-reported M_R CRIs,
Even sub-bands (G1) of the 1^st reported CRI,
Odd sub-bands (G2) of the 1^st reported CRI,
…,
Even sub-bands (G1) of the (M-M_R)^th reported CRI,
Odd sub-bands (G2) of the (M-M_R)^th reported CRI.

Note: For UCI fields in wideband (G0), even sub-bands (G1), and odd sub-bands (G2), legacy design is fully reused.

Agreement

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports, the UCI parameters are captured in the tables below for Scheme-B for RI=5-8:

· Note: The second column includes the location of the parameters when reported with two-part UCI

Scheme-B

Parameter	UCI	Details/description
SD basis oversampling (rotation) factor q₁, q₂	Part 2 Wideband	v=5-8: Values of q₁, q₂ follow Rel-16 eType-II, bit indicator
SD basis vector selection indicator for each layer	Part 2 Wideband	v=5-8: bit indicator, where L_G=3 for v=5-6, and 4 for v=7-8
Inter-pol co-phase selection indicator for each layer	Part 2 Wideband or Subband (**)	v=5-8: QPSK: 2-bit indicator per layer group l=1, …,

(*): Not included when CQI reporting granularity is set to ‘wideband’

(**): Wideband when PMI reporting is set to ‘wideband’, Subband when PMI reporting granularity is set to ‘subband’

Conclusion

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports, conditioned in UE capabilities, a UE can be configured with either the group-based hard CBSR, or the 3-bit SD basis group-based scaling factor, or both, or none of the two.

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset), the selection of P_SRS=1 SRS port corresponding to the ‘reference UE antenna port’ (out of available port(s)) is NW-configured via higher-layer (RRC) signalling.

Working Assumption

For the Rel-19 aperiodic standalone CJT calibration reporting, when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset), the configured associated SRS resource can be either periodic, semi-persistent, or aperiodic.

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, regarding the resolution for delay offset reporting D_n,offset, additionally support M_D = {128, 256}.

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset), regarding the support of sub-band reporting (S>1):

Denoting the number of reported sub-band phase-offset values as N_SB-P, and the sub-bands are indexed as {0, 1, …, N_SB-P–1}, support, as a separate UE capability from wideband (S=1) phase offset reporting, reporting, in one CSI reporting instance, {(F_n,₀, F_n,_1,..._, F_n,NSB-P_-1), n=0, 1, …, N_TRP – 1, n≠nref}

The alphabet for F_n,_sfollows the previously agreed alphabet for S=1, including the ‘invalid’ state

FFS:

Supported sub-band size(s), e.g. following the legacy CSI sub-band definition, vs {1, 2, 4, 8, 16 PRBs}
Whether the UE performs measurement over the entire configured CSI reporting band W_CSI
If needed, mechanism to limit CSI reporting overhead (e.g. maximum N_SB-P)
If needed, configuration of whether the CSI-RSs are MRT-beamformed in frequency-domain or not

Note: UE is not required to perform DO/FO compensation for sub-band phase offset calculation

Note: There is a source R1-2407184 showing for frequency-domain-MRT-precoded CSI-RSs, inter-TRP phase has a linear rotation in frequency-domain, and is associated with a single delay component.

Agreement

For the 3-bit scaling scheme for Type-I SP codebook, support, in addition, (X₁, X₂)=(8,1).

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, support resource-specific RI restriction.

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, O_CPU = K_S.

R1-2407283 Moderator Summary on Wednesday offline for Rel-19 CSI enhancements Moderator (Samsung)

R1-2407280 Moderator Summary#3 on Rel-19 CSI enhancements: Round 3 Moderator (Samsung)

From Wednesday session

Agreement

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports, for Scheme-A RI=5-8, the UCI parameters for the selection scheme for the other SD basis vectors (in Part 2 UCI, wideband) are as follows:

A 1-bit beam group indicator i₃∈{0,1}
For each of the n_SDBV other selected SD basis vectors,

If i₃=0:

-bit, -bit, and -bit (q₂) indicators

In this case, q₁ = mod(i₁,O₁) of the first SD basis vector

If i₃=1:

-bit, -bit, and -bit (q₁) indicators

In this case, q₂= mod(i₂,O₂) of the first SD basis vector

Note: It is up to the editor how this is captured in the specification

Note: (q₁,q₂) is analogous to (q₁,q₂) for Type-II CSI

Note (from previous agreement): n_SDBV=2 (v=5-6) or 3 (v=7-8)

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, regarding UCI omission for the UCI reported in CSI part-1, CSI part-1 is either reported entirely or dropped entirely, with the following UCI packing order:

· CSI part-1 associated with the first configured CMR among the non-reported M_R CRIs

· …

· CSI part-1 associated with the last configured CMR among the non-reported M_R CRIs

· CSI part-1 of the 1^st reported CRI,

· …

· CSI part-1 of the (M-M_R)^th reported CRI,

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset), regarding the support of sub-band reporting (S>1) {(F_n,₀, F_n,_1,..._, F_n,NSB-P_-1), n=0, 1, …, N_TRP – 1, n≠nref}:

Supported sub-band size(s) {1, 2, 4, 8, 16} PRB
The NW configures, via higher-layer (RRC) signalling, which N_SB-P sub-band(s) the UE reports.

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports based on Rel-16 eType-II, regarding UCI omission for the UCI reported in CSI part-2, other than priority 0 (G0), the UCI packing order and the 2M consecutive priority levels are defined w.r.t the M CRIs (including the non-reported M_R CRIs) as follows:

Consecutive priority levels (higher to lower):

G1 PMI components associated with the first configured CMR among the non-reported M_R CRIs,
G2 PMI components associated with the first configured CMR among the non-reported M_R CRIs,
…,
G1 PMI components associated with the last configured CMR among the non-reported M_R CRIs,
G2 PMI components associated with the last configured CMR among the non-reported M_R CRIs,
G1 PMI components of the 1^st reported CRI,
G2 PMI components of the 1^st reported CRI,
…,
G1 PMI components of the (M-M_R)^th reported CRI,
G2 PMI components of the (M-M_R)^th reported CRI.

Note: For UCI fields in wideband (G0), G1 PMI components (based on Rel-16 eType-II CB in Section 6.3.2.1.2, TS 38.212), and G2 PMI components, legacy design is fully reused.

Agreement

For the Rel-19 aperiodic standalone CJT calibration (CJTC) reporting, when ReportQuantity is ‘cjtc-P’ (PO) and S=1:

The UCI parameters are captured in the tables below:

Parameter

Details/description

nref

Reference CSI-RS resource index, based on the ordering from RRC configuration: bits

{F_n,

n=0, 1, …, N_TRP –1, n≠nref}

DL/UL phase offset for CSI-RS resource n:

bits

The UCI mapping order is as follows:

o nref,

o {F_n, n=0, 1, …, N_TRP – 1, n≠nref} ordered from the lowest to highest CSI-RS resource ID

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, regarding timeline:

· Multiply legacy Z’ by a factor of 2

· Multiply legacy Z by a factor of 2

Agreement

For the Rel-19 aperiodic standalone CJT calibration (CJTC) reporting, to facilitate UE-specific delay offset pre-compensation on PDSCH by the NW, support configuring a UE (via RRC signaling) to perform PMI calculation for the Rel-18 eType-II CJT CSI report assuming pre-compensation using the UE-reported delay offset (when ReportQuantity is ‘cjtc-Dd’).

The two separately configured reports (i.e. Rel-18 eType-II CJT CSI report and the CJTC delay offset report) can be separately or jointly triggered [and carried on a same PUSCH (hence on a same slot)] following legacy joint triggering mechanism

(Working Assumption) When separately triggered, the delay offset value to be compensated is the latest reported delay offset (DO) whose reporting instance’s last symbol is before the first symbol of DCI triggering of the CJT CSI reporting

FFS: whether some expiration time interval is needed

(Working Assumption) When jointly triggered, the delay offset value to be compensated is the reported delay offset (DO) in the same reporting instance

FFS: NW indicates the delay offset value to be compensated for the Rel-18 eType-II CJT CSI report

FFS: Whether only AP-CSI-RS, or any type of CSI-RS (P, SP, or AP) can be configured as the CMR for the Rel-18 eType-II CJT reporting

FFS: Support for SP-CSI for CJTC report

FFS: Whether this is also applicable for Rel-19 Type-I MP codebook

The above only applies when the CMRs do not share common QCL source for average delay indication

The above is UE optional feature.

R1-2407466 Moderator Summary on Thursday offline for Rel-19 CSI enhancements Moderator (Samsung)

R1-2407281 Moderator Summary#4 on Rel-19 CSI enhancements: Round 4 Moderator (Samsung)

From Thursday session

Agreement

For the Rel-19 Type-I codebook refinement for 48, 64, and 128 CSI-RS ports, study, for RI= >1, applying the 3-bit scaling factor(s) as agreed in RAN1#117, where a per-layer scaling factor applied to the selected SD basis vector is given by e.g. , where unit scaling factor “1” is associated with the PDSCH-to-CSIRS EPRE offset “portion” contributed by the selected SD basis vector without the 3-bit scaling factor configured, e.g. is the scaling factor associated with the SD basis vector, and is the number of layers transmitted using the SD basis vector.

Note: This feature is a separate UE capability
Study whether per-SD-basis-vector/layer power adjustment (including boosting) needs to be supported in addition

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, regarding resource-specific CBSR,

For Rel-16 eType-II-based: reuse Rel-16 eType-II CBSR design for each of the K_S resources:

Just as Rel-18 Type-II CJT CBSR, decouple (N1,N2) from each of the K_S CBSR IEs
This implies that it is possible not to configure CBSR for any of the KS resources
Only 1-bit hard CBSR is supported

For Rel-15 Type-I-SP-based: reuse Rel-15 Type-I SP CBSR design for each of the K_S resources:

Just as Rel-18 Type-II CJT CBSR, decouple (N1,N2) from each of the Ks CBSR IEs
This implies that it is possible not to configure CBSR for any of the KS resources

9.2.3 Support for 3-antenna-port codebook-based transmissions

R1-2405872 On codebook for 3-antenna-port UL transmission Huawei, HiSilicon

R1-2405877 On Rel-19 CB-based UL for 3TX UE InterDigital, Inc.

R1-2405889 Support for 3-antenna-port codebook-based transmissions MediaTek Inc.

R1-2405905 Discussion on 3-antenna-port codebook-based transmissions Spreadtrum Communications

R1-2405956 Uplink 3 Port Codebook based Transmission Google

R1-2405982 Discussion on support for 3-antenna-port codebook-based transmissions CMCC

R1-2406025 Support for 3Tx UL MIMO Intel Corporation

R1-2406030 Discussion on 3-antenna-port codebook-based transmissions ZTE Corporation, Sanechips

R1-2406179 Discussion on 3-antenna-port codebook-based uplink transmissions vivo

R1-2406262 Discussion on 3-antenna-port codebook-based transmissions OPPO

R1-2406281 Discussion on the support of 3-antenna-port CB based transmissions Xiaomi

R1-2406312 Discussion on uplink enhancement for UE with 3Tx Fujitsu

R1-2406365 On support for 3-antenna-port codebook-based transmissions CATT

R1-2406523 Support for 3-antenna-port codebook-based transmissions Lenovo

R1-2406549 Discussion on 3-antenna-port codebook-based transmissions NEC

R1-2406646 Views on Rel-19 3-antenna-port codebook-based transmissions Samsung

R1-2406747 On the support for 3-antenna-port codebook-based transmissions Nokia

R1-2406833 Views on R19 3Tx codebook based transmission Apple

R1-2406927 Discussion on support for 3-antenna-port codebook-based transmissions NTT DOCOMO, INC.

R1-2407004 Support for 3-antenna-port codebook-based transmission Sharp

R1-2407026 3 Tx UL MIMO transmissions Qualcomm Incorporated

R1-2407182 Support for 3 Tx UL Transmissions Ericsson

R1-2405879 Summary of Offline Discussions on 3TX CB-based Uplink Moderator (InterDigital, Inc.)

R1-2405880 FL Summary Support for 3TX CB-based Uplink; First Round Moderator (InterDigital, Inc.)

From Monday session

Proposal:

Support introduction of a new RRC parameter for enabling a configured 4-port SRS resource with port 1003 disabled.

Objected by vivo, Xiaomi

Conclusion:

Support to reuse SRS features (i.e., cyclic shift hopping, and comb offset hopping) in Rel-18 for SRS resource set with usage of codebook based 3TX PUSCH transmission, without introducing new UE capabilities (i.e., reusing Rel-18 UE capabilities).

Note: The conclusion does not include the Rel-18 8-port-specific SRS features.

R1-2405881 FL Summary Support for 3TX CB-based Uplink; Second Round Moderator (InterDigital, Inc.)

From Wednesday session

Proposal:

Support introduction of a new RRC parameter for enabling a configured 4-port SRS resource with port 1003 disabled.

From Thursday session

Agreement

For a UE reporting UE capability of 3TX operation, support introduction of a new RRC parameter for enabling a configured 4-port SRS resource with port 1003 disabled.

R1-2405882 Recommended Direction on 3TX CB-based Uplink in RAN1#118b Moderator (InterDigital, Inc.)

9.2.44 Enhancement for asymmetric DL sTRP/UL mTRP scenarios

R1-2405873 Enhancements for asymmetric DL sTRP/UL mTRP scenarios Huawei, HiSilicon

R1-2405878 On Rel-19 Asymmetric mTRP Operation InterDigital, Inc.

R1-2405890 Enhancement for asymmetric DL sTRP/UL mTRP scenarios MediaTek Inc.

R1-2405906 Enhancements for asymmetric DL sTRP/UL mTRP scenarios Spreadtrum Communications

R1-2405937 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Tejas Networks Limited

R1-2405983 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios CMCC

R1-2406026 Enhancements for asymmetric DL/UL scenarios Intel Corporation

R1-2406031 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios ZTE Corporation, Sanechips, China Telecom

R1-2406086 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios China Telecom, ZTE

R1-2406180 Discussion on asymmetric DL sTRP/UL mTRP scenarios vivo

R1-2406263 Enhancements on asymmetric DL sTRP/UL mTRP scenarios OPPO

R1-2406265 Discussion on asymmetric DL sTRP/UL mTRP scenarios TCL

R1-2406282 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios Xiaomi

R1-2406313 Discussion on UL-only mTRP operation Fujitsu

R1-2406366 On asymmetric DL sTRP/UL mTRP scenarios CATT

R1-2406455 Enhancement for Asymmetric DL sTRP/UL mTRP Scenarios Panasonic

R1-2406469 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Sony

R1-2406524 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Lenovo

R1-2406544 Discussion on enhancements for asymmetric DL sTRP and UL mTRP scenarios NEC

R1-2406647 Views on Rel-19 asymmetric DL sTRP/UL mTRP scenarios Samsung

R1-2406701 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios Transsion Holdings

R1-2406724 Discussion on UL enhancement through asymmetric DL and UL ETRI

R1-2406748 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Nokia

R1-2406803 Enhancement for asymmetric DL sTRP UL mTRP scenarios Ericsson

R1-2406834 Enhancements for asymmetric DL sTRP/UL mTRP Apple

R1-2406928 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios NTT DOCOMO, INC.

R1-2407005 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Sharp

R1-2407027 Enhancement for asymmetric DL sTRP and UL mTRP deployment scenarios Qualcomm Incorporated

R1-2407112 Discussion on enhancement for asymmetric DL sTRP and UL mTRP scenarios Google

R1-2407123 Discussion on asymmetric DL sTRP and UL mTRP ASUSTeK

R1-2407189 Summary #1 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

From Monday session

Agreement

For indicating a PL offset for PDCCH-order PRACH transmission at least for FR1, support Alt3:

Alt3: The PL offset associated with one of the indicated joint/UL TCI state for UL TRP in unified TCI framework is applied on the PDCCH-order PRACH transmission.

FFS the detailed design of DCI format: e.g., how to indicate one of the indicated joint/UL TCI states or whether to apply the PL offset in the indicated TCI state or not.

Agreement

For the asymmetric DL sTRP/UL mTRP scenarios, the value range of PL offset includes at least [-10, 60] dB.

FFS: Extending the range to lower than -10dB
Step size is 4dB

Agreement

For the asymmetric DL sTRP/UL mTRP scenarios, support to include PL offset in the calculation of Type 1 PHR based on actual PUSCH transmission and Type 1 PHR based on reference PUSCH.

R1-2407190 Summary #2 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

From Wednesday session

Agreement

Study whether to support Type 3 PHR reporting in a serving cell/BWP where the UE is configured with two separate SRS CLPC adjustment states.

Continue to study whether to support including PL offset in the calculation of Type 3 PHR.

Agreement

About the extended value range 1~X of starting bit of blocks in DCI format 2_3 in Rel-19, down-select one from the following Alts in RAN1#118bis:

Alt1: X = 45 (to be captured in RAN2 spec)

This feature is a separate UE capability and is appliable to any rel-19 UE who supports this UE capability, regardless this UE supports two separate SRS CLPC adjustment states or not.
Note: X=45 can be used for operations in FR1 in shared spectrum or FR2-2 and X = 43 otherwise.

Alt2: X = 44 (to be captured in RAN2 spec)

This feature is only applicable to UE who is configured with two separate SRS CLPC adjustment states.
Note: X=44 can be used for operations in FR1 in shared spectrum for FR2-2 and X = 42 otherwise.

Above extended value range is applied to startingBitOfFormat2-3.

Agreement

Study whether/how to apply PL offset for SRS resource set when the SRS resource set is not configured with TCI state.
Study whether/how to apply one of the two separate SRS CLPC adjustment states on the SRS resource set when the SRS resource set is not configured with TCI state.

E.g., defining i0 as the default CLPC for SRS resource set in this case. E.g,, configure one of the separate SRS CLPC adjustment states to the SRS resource set.

Final summary in R1-2407191.

RAN1#118-bis

9.2 NR MIMO Phase 5

Please refer to RP-242394 for detailed scope of the WI.

[118bis-R19-MIMO] – Eko (Samsung)

Email discussion on Rel-19 MIMO Phase 5

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2408641 List of RRC and MAC CE impact for Rel-19 MIMO Ph5 Samsung, MediaTek, CMCC, Interdigital, OPPO, ZTE

9.2.1 Enhancements for UE-initiated/event-driven beam management

R1-2407622 Enhancements for UE-initiated/event-driven beam management FUTUREWEI

R1-2407678 On UE initiated/event-driven beam management Huawei, HiSilicon

R1-2407698 Discussion on UE-initiated/event-driven beam management Spreadtrum Communications

R1-2407773 Discussion on enhancements for UE-initiated/event-driven beam management ZTE Corporation, Sanechips

R1-2407812 UE-initiated/event-driven beam management MediaTek Inc.

R1-2407853 Remaining issues on UE-initiated/event-driven beam management vivo

R1-2407897 Discussion on enhancements for UE-initiated/event-driven beam management CMCC

R1-2407961 Enhancements for UE-initiated/event-driven beam management Xiaomi

R1-2408039 Enhancement for UE-initiated/event-driven beam management CATT

R1-2408083 Discussion on UE-initiated/event-driven beam management TCL

R1-2408108 Discussion on enhancements for UE-initiated/event-driven beam management Fujitsu

R1-2408117 Enhancements for UE-initiated/event-driven beam management Transsion Holdings

R1-2408164 Discussions on UE-initiated/event-driven beam management OPPO

R1-2408187 Discussion on Rel-19 UE/Event-Driven Beam Management InterDigital, Inc.

R1-2408199 Enhancements for UE-initiated/event-driven beam management Lenovo

R1-2408223 Discussion on enhancements for UE-initiated or event-driven beam management NEC

R1-2408230 Discussion on the UE-initiated/event-driven beam management HONOR

R1-2408296 Enhancements for Event-driven Beam Management Intel Corporation

R1-2408317 Offline summary for Rel-19 MIMO UEIBM (9.2.1) pre-RAN1#118bis Moderator (ZTE)

R1-2408336 UE-initiated beam management LG Electronics

R1-2408348 Enhancements for UE-initiated/event-driven beam management Sharp

R1-2408368 Discussion on enhancements for UE-initiated or event-driven beam management Google

R1-2408382 Discussion on enhancements for UE-initiated/event-driven beam management Ruijie Networks Co. Ltd

R1-2408404 Enhancements for UE-initiated/event-driven beam management Sony

R1-2408457 Enhancements for UE-initiated beam management Apple

R1-2408562 Enhancements for UE-initiated/event-driven beam management ETRI

R1-2408610 Remaining issues for UE-initiated beam management Ericsson

R1-2408635 Views on Rel-19 UE-initiated/event-driven beam management Samsung

R1-2408738 Enhancements to facilitate UE-initiated/event-driven beam management Nokia

R1-2408748 Enhancements for UE Initiated Beam Management Meta

R1-2408778 Discussion on enhancements for UE-initiated/event-driven beam management NTT DOCOMO, INC.

R1-2408827 Discussion on UE-initiated/event-driven beam management ITRI

R1-2408842 UE-initiated/event-driven beam management Qualcomm Incorporated

R1-2408881 Enhancements for UE-initiated/Event-Driven Beam Management Panasonic

R1-2408890 Discussion on UE initiated beam report ASUSTeK

R1-2408911 Discussions on enhancements for UE-initiated/event-driven beam management KDDI Corporation

R1-2408925 Enhancements for UEiBM CEWiT

R1-2408940 Discussion on enhancements for UE-initiated or event-driven beam management NICT

R1-2408318 Moderator Summary #1 on UE-initiated/event-driven beam management Moderator (ZTE)

From Monday session

Agreement

On UE-initiated/event-driven beam reporting, regarding L1-RSRP report format Option-3 depending on Event-2,

· The differential L1-RSRP is quantized to a 4-bit value with 2 dB step size

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the triggering procedure in Step-2 of Mode-A

Reuse CSI request field in DCI format 0_1/0_2 to trigger the transmission of the UEI beam report

If a CSI trigger state associated with UEI beam report configuration(s) is indicated by the CSI request field in DCI format 0_1/0_2, the UE transmits the corresponding UEI beam report(s) in the second PUSCH scheduled by the DCI format 0_1/0_2
FFS: DCI format 0_3

FFS: Whether a CSI trigger state should be dedicated to UE-initiated/event-driven beam reporting, i.e., not associated with legacy AP-CSI report configuration.

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, resource mapping/configuration between first and second UL channel in Mode-B, at least Option-1 is supported

· Option-1 (one-to-one): Only one periodic PUCCH resource for the first channel and only one pre-configured resource for second UL channel can be associated with the CSI report configuration for UE-initiated/event-driven beam reporting.

o Down-select one of the following in RAN1#118bis

§ Option-1A: Same periodicity between first PUCCH resource and pre-configured resource for second UL channel.

§ Option-1B: No restriction in terms of periodicity.

R1-2408319 Moderator Summary #2 on UE-initiated/event-driven beam management Moderator (ZTE)

From Tuesday session

Agreement

On cross-CC beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Event-2, for both Mode-A and Mode-B, the first PUCCH and the second PUSCH can be from the same or different CC(s)

FFS: whether the first PUCCH and the second PUSCH should be from the same PUCCH group
The first PUCCH and the second PUSCH should be in the same CG

FFS: Different CGs

Agreement

· Option-1: The same Type-1 CG PUSCH can carry UL-SCH, any other UCI, and the beam report.

· Option-2: The Type-1 CG PUSCH is a dedicated type-1 CG PUSCH for carrying the beam report

o Note: This PUSCH can NOT carry UL-SCH. This PUSCH can NOT carry any other UCI.

· Option-3: The Type-1 CG PUSCH is a type-1 CG PUSCH for carrying the beam report

o Note: This PUSCH can NOT carry UL-SCH. This PUSCH can carry any other UCI.

FFS: whether Type-1 CG PUSCH can be transmitted if the pre-configured Type-1 CG PUSCH does NOT carry the beam report.

Working Assumption

The following working assumption in RAN1#118 is revised in red.

On UE-initiated/event-driven beam reporting, regarding trigger events, besides for Event-2, Event-1 and Event-7 are both supported.

· Event-1: Quality of the current beam is worse than a certain threshold.

· Event-7: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the ~~M-th~~ Q-th best quality.

o M Q is RRC configured with subjective to UE capability signalling

§ UE may only indicate a single candidate value or not support Event-7.

· The additionally supported events will reuse the same design as event 2 – unless there is consensus to do otherwise

· The additionally supported events will be lower priority compared to event 2.

R1-2408320 Moderator Summary #3 on UE-initiated/event-driven beam management Moderator (ZTE)

From Wednesday session

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding resource mapping/configuration between first and second UL channel associated with a same CSI report configuration in Mode-B,

· The UE expects that there is the same periodicity (in ms) between first PUCCH resource and pre-configured resource for second UL channel.

o FFS: Whether first PUCCH resource and pre-configured resource for second UL channel can have different periodicities (in ms).

Agreement

Regarding RS measurement for the current beam for Event 2, for Option-2a, besides for scheme-1 and scheme-2, there is no RAN1 consensus on the following enhancement for handling the case that only one TRS is configured in the indicated TCI state in RAN1#118bis

Option-1: Introducing additional scheme: the RS for current beam can be a CSI-RS for beam management derived from the QCL RS in the indicated TCI state;
Option-2: Further support TRS as measurement RS of current beam for determining L1-RSRP
Option-3: Introducing additional scheme: The RS for current beam is explicitly configured by RRC or MAC-CE (Option-2C in RAN1 116b agreement).

Note 3: When only one TRS is configured in the indicated TCI state, either Scheme-1(working assumption) or Scheme-2 is used where enabling one of either Scheme-1 or Scheme-2 is selected by NW.

When the Scheme-1 is used, the UE assumes that the CSI-RS resource in the indicated TCI state is configured in a CSI-RS resource set configured with repetition.

R1-2409212 Moderator Summary #4 on UE-initiated/event-driven beam management Moderator (ZTE)

From Thursday session

Agreement

Regarding RS measurement for the current beam for Event 2, for Option-2a, confirm the following working assumption

· Note 3: When only one TRS is configured in the indicated TCI state, either Scheme-1~~(working assumption)~~ or Scheme-2 is used where enabling one of either Scheme-1 or Scheme-2 is selected by NW.

Agreement

Regarding RS measurement for the current beam for Event 2, for Option-2a, the following working assumption in RAN1#117 is confirmed with modification:

(Working Assumption) Enabling of either Scheme-1 or Scheme-2 should ensure the same RS type for RS measurement for current beam and new beam.

Note: In such case, the RS type comprises SSB and CSI-RS configured in a CSI-RS resource set configured with repetition.

Agreement

Regarding RS measurement for the current beam for Event 2, for enabling one of either Scheme-1 or Scheme-2 by NW in Option-2a, the following implicit manner is supported:

· If the RS(s) for new beam are CSI-RS configured in a CSI-RS resource set configured with repetition, Scheme-1 is enabled; otherwise, Scheme-2 is enabled.

Agreement

Regarding the triggering event determination for Event 2, the event instance(s) counting is per new beam. Further study candidate condition(s) of resetting the counting including whether resetting is needed.

Agreement

Regarding the triggering event determination for Event 2, down-select among the following alternatives for the evaluation periodicity for determining Event-2 instance [at least when DRX is not configured]

Alt-1: The periodicity of the current beam RS should be the same as that of the new beam RS(s).

The evaluation periodicity is the same as the periodicity of the current and new beam RS(s)

Alt-2: The periodicity of the current beam RS can be different from that of the new beam RS(s)

Alt-2_1: The evaluation periodicity is the same as the periodicity of the current beam RS;
Alt-2_2: The evaluation periodicity is the same as periodicity of the new beam RS;
Alt-2_3: The evaluation periodicity is the same as shortest periodicity of the current beam RS and new beam RS(s):
Alt-2_4: The evaluation periodicity is the maximum of {X ms, shortest periodicity of the current beam RS and new beam RS(s)}:
Alt-2_5: The evaluation periodicity is the same as largest periodicity of the current beam RS and new beam RS(s):

~~FFS: Whether the periodicity of the current beam RS should be the same as that of the new beam RS(s).~~

Note: There is the same periodicity for the new beam RS(s).

Agreement

On cross-CC beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Event-2, the following is supported

· For new beam measurement, in a CSI report configuration, configure legacy RRC parameter carrier that indicates the CC that the RS resource set associated with the CSI reporting configuration can be found

· FFS: Whether the current beam RS and new beam RS(s) can be in the same CC or in different CCs, regarding cross-CC beam measurement.

· FFS: Whether the indicated TCI state and new beam RS(s) can be in the same CC or in different CCs, regarding cross-CC beam measurement.

Conclusion

There is no RAN1 consensus on the following proposal:

On UE-initiated/event-driven beam reporting, regarding L1-RSRP report format Option-3 depending on Event-2, the candidate value of ‘N’ can further comprise {5, 6, 7, 8}, besides for previously agreed candidate value of {1, 2, 3, 4}.

9.2.2 CSI enhancements

Including support for up to 128 CSI-RS ports on FR1 and UE reporting enhancement for CJT and SRS port grouping for TDD low-complexity 6/8RX receiver.

R1-2407679 On 128 CSI-RS ports and UE reporting enhancement Huawei, HiSilicon

R1-2407699 Discussion on CSI enhancements Spreadtrum Communications

R1-2407755 CSI enhancements Tejas Network Limited

R1-2407774 Discussion on CSI enhancements ZTE Corporation, Sanechips

R1-2407813 CSI enhancements MediaTek Inc.

R1-2407824 Discussion on Rel-19 CSI enhancements New H3C Technologies Co., Ltd.

R1-2407854 Remaining issues on Rel-19 CSI enhancements vivo

R1-2407898 Discussion on CSI enhancements CMCC

R1-2407962 Discussion on Rel-19 MIMO CSI enhancements Xiaomi

R1-2407993 CSI Enhancement for NR MIMO Google

R1-2408040 On Rel-19 MIMO CSI enhancements CATT

R1-2408109 Discussion on Rel-19 CSI enhancements Fujitsu

R1-2408165 CSI enhancements for Rel-19 MIMO OPPO

R1-2408188 Discussion on Rel-19 Enhancements of CSI InterDigital, Inc.

R1-2408200 Discussion on CSI enhancements Lenovo

R1-2408210 Discussion on CSI enhancements NEC

R1-2408231 Discussion on CSI enhancements HONOR

R1-2408295 CSI enhancements for MIMO Intel Corporation

R1-2408337 Discussions on CSI enhancements LG Electronics

R1-2408349 CSI enhancements Sharp

R1-2408395 CSI enhancements for Rel. 19 MIMO Fraunhofer IIS, Fraunhofer HHI

R1-2408405 More views on CSI enhancements Sony

R1-2408458 Views on R19 MIMO CSI enhancement Apple

R1-2408496 Discussion on CSI enhancements TCL

R1-2408563 Discussion on Rel-19 CSI enhancements ETRI

R1-2408638 Views on Rel-19 CSI enhancements Samsung

R1-2408739 CSI enhancement for NR MIMO Phase 5 Nokia

R1-2408779 Discussion on CSI enhancements NTT DOCOMO, INC., NTT CORPORATION

R1-2408843 CSI enhancements for >32 ports and UE-assisted CJT Qualcomm Incorporated

R1-2408876 CSI enhancements for large antenna arrays and CJT Ericsson

R1-2408926 CSI Enhancements CEWiT

R1-2408948 Discussion on CSI enhancements for NR MIMO Phase 5 KDDI Corporation

R1-2408964 Discussion on CSI enhancements NICT

R1-2408636 Moderator summary for OFFLINE discussion on Rel-19 CSI enhancements Samsung (Moderator)

R1-2408637 Moderator summary on Rel-19 CSI enhancements Samsung (Moderator)

From Monday session

Agreement

· SRS port group 0, corresponding to CW0, comprises the even P_SRS/2 out of P_SRS ports; and

· SRS port group 1, corresponding to CW1, comprises the odd P_SRS/2 out of P_SRS ports

The above feature is applicable only for reportQuantity = ‘cri-RI-CQI’.

No other spec enhancement is introduced on new CW-to-layer mapping, DL resource allocation, CSI feedback, and DCI format

Note: The above grouping assumption is to align NW and UE on the association between SRS ports and reported CQIs for the two CWs when reportQuantity = ‘cri-RI-CQI’.

Note: different SRS ports are associated with different UE antenna ports.

Note: if one single CW is scheduled, both SRS port groups can correspond to the same CW, i.e. no enhancement is needed for the single-CW case.

Note: This feature is a separate UE capability and, for UEs supporting this capability, configured via RRC (FFS details on the extend of RRC configuration).

Note: Whether to support 6Rx with more than 4 layers is to be decided in RAN4 Rel-19 RF enhancements WI.

FFS (by RAN1#118bis): Whether there is impact on mapping between CWs to CSI-RS ports.

For SRS antenna switching with multiple aperiodic SRS resource sets, P_SRS ports indexed in an ascending order according to SRS resource set ID and SRS resource ID in a set and port number within each SRS resource.

Agreement

For the Rel-19 Type-I SP and Type-II codebook refinements (except based on Rel-18 Type-II Doppler) for 48, 64, and 128 CSI-RS ports, active resource counting is:

· For Capability 1 timeline: 1

· For Capability 2 timeline: 1

Agreement

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports, regarding the support for the 3-bit scaling factor(s) for RI=v >1, support only for RI=v=2 without per-SD-basis-vector/layer power adjustment/boosting

FFS: Details on per-layer scaling factor applied to each of the selected SD basis vectors, extending the agreed scaling factor for RI= v =1 (in RAN1#117)

This feature is a separate UE capability from soft scaling for RI=v=1. Introduce new RRC parameter to enable the feature.

Note: This doesn’t preclude the use of power boosting at the NW side by implementation.

Agreement

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports, the inter-pol co-phase selection indicator row from the UCI parameter table for Scheme-B for RI=5-8 is amended as follows:

Scheme-B

Parameter

UCI

Details/description

…

Inter-pol co-phase selection indicator for each layer

Part 2

Wideband or Subband (**)

v~~=5-8:~~ ~~QPSK: 2-bit indicator per layer group l=1, …,~~

v=5, 7: QPSK:

· For a layer group with 2 layers: 1-bit indicator {(1, -1), (j, -j)}

· For a layer group with 1 orphan layer: 2-bit indicator {1, -1, j, -j}

v=6, 8: QPSK:

· 1-bit indicator for each layer group {(1, -1), (j, -j)}

Agreement

For the Rel-19 Type-I SP codebook refinement for P (the total number of aggregated ports)=48, 64, 128 CSI-RS ports, regarding timeline for the port subset indication for the SD NES Type-1,

Capability 1 timeline: Reuse legacy Z/Z’ values (i.e., Z₂ and Z’₂)
Capability 2 timeline: Scale the legacy timeline Z/Z’ (i.e., Z₂ and Z’₂) by where M is the number of sub-configurations that refer to the any of the K aggregated CSI-RS resources

Agreement

For the Rel-19 Type-I SP codebook refinement for P (the total number of aggregated ports)=48, 64, 128 CSI-RS ports, regarding active resource/port counting for the port subset indication for the SD NES Type-1,

active resource counting is , where M is the number of sub-configurations that refer to the any of the K aggregated CSI-RS resources
active port counting is , where is the number of CSI-RS ports in i-th sub-configuration derived from the corresponding antenna port subset indicator portSubsetIndicator

Agreement

For the Rel-19 Type-I and Type-II codebook refinement for 48, 64, and 128 CSI-RS ports, when a CSI-RS resource set for aggregating K NZP CSI-RS resources (to attain a total of 48, 64, and 128 ports) is configured as the associated NZP CSI-RS for each of the SRS resource set(s) with higher layer parameter usage in SRS-ResourceSet set to ‘nonCodebook’, support to change the starting position of the time gap between CSI-RS and SRS from the last symbol of the reception of the aperiodic NZP-CSI-RS resource to the last symbol of the reception of the aperiodic NZP-CSI-RS resource set.

Agreement

For the Rel-19 Type-I and Type-II codebook refinement for 48, 64, and 128 CSI-RS ports, except for that based on the Rel-18 Type-II Doppler, the following rule is supported:

· After the CSI report (re)configuration, serving cell activation, BWP change, or activation of SP-CSI, the UE reports a CSI report only after receiving at least one CSI-RS transmission occasion for each of the CSI-RS resources in the corresponding CSI-RS resource set for channel measurement and at least one CSI-RS and/or CSI-IM resource transmission occasion for each of the CSI-RS and/or CSI-IM resources in the corresponding resource set for interference measurement no later than the CSI reference resource and within the same DRX active time, when DRX is configured, and drops the report otherwise.

Agreement

For the Rel-19 Type-II codebook refinement for 48, 64, and 128 CSI-RS ports based on the Rel-18 Type-II Doppler, the following rule is supported:

· After the CSI report (re)configuration, serving cell activation, BWP change, or activation of SP-CSI, the UE reports a CSI report only after receiving at least one aperiodic or K_P consecutive periodic/semi-persistent CSI-RS transmission occasion(s) for each of the CSI-RS resources in each CSI-RS resource group in the corresponding CSI-RS resource set for channel measurement and at least one CSI-RS and/or CSI-IM resource transmission occasion for each of the CSI-RS and/or CSI-IM resources in the corresponding resource set for interference measurement no later than the CSI reference resource and within the same DRX active time, when DRX is configured, and drops the report otherwise.

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, regarding priority 0 (G0) in CSI part 2, the UCI packing order is as follows:

The G0 for the 1^st configured CMR among the non-reported M_R CRIs;
…
The G0 for the last configured CMR among the non-reported M_R CRIs;
The G0 for the 1^st reported CRI;
…
The G0 for the (M- M_R)-th reported CRI;

The entire G0 is either reported or dropped entirely, following the legacy principle.

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports,

the following rule is supported:

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset), the selection of P_SRS=1 SRS port (corresponding to the ‘reference UE antenna port’) out of the y available SRS ports (from an xTyR SRS resource for antenna switching) can be configured per CSI reporting setting.

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset), regarding the configured associated SRS resource,

Confirm the following working assumption as agreement: “the configured associated SRS resource can be either periodic, semi-persistent, or aperiodic”

· When periodic or semi-persistent associated SRS resource is configured, the SRS transmission occasion for determining the reference UE antenna port corresponds to the latest SRS transmission occasion before the occasions of the N_TRP CSI-RS resources used for measuring ‘cjtc-P’ report

FFS: Whether ‘the earliest SRS transmission occasion after the N_TRP CSI-RS occasions’ is also supported as an option
FFS: Whether determination of SRS transmission occasion is needed for aperiodic associated SRS resource, and if so, how

Agreement

For the Rel-19 aperiodic standalone CJT calibration (CJTC) reporting, when linking CJTC Dd and Rel-18 eType-II CJT CSI reports is configured, confirm the following working assumptions as agreement with the following refinement:

When separately triggered, the delay offset value to be compensated is the latest reported delay offset (DO) whose reporting instance’s last symbol is before the first symbol of DCI triggering of the CJT CSI reporting
When jointly triggered, the delay offset value to be compensated is the reported delay offset (DO) in the same reporting instance

FFS: Whether an additional UE procedure is needed when the reported DO value is ‘out of range’

FFS: Whether the Dd report codepoints need to be reinterpreted from intervals/ranges to values when the linkage mechanism is configured, or in general, a rule is needed to determine the value of DO for the compensation for each CMR for CJT CSI report (including if multiple Dos are reported)

Agreement

For the Rel-19 aperiodic standalone CJT calibration (CJTC) reporting, when linking CJTC Dd and Rel-18 eType-II CJT CSI reports is configured, support at least AP-CSI-RS as the CMR for the Rel-18 eType-II CJT reporting

FFS: The support for P/SP CSI-RS

Agreement

For the Rel-19 aperiodic standalone CJT calibration (CJTC) reporting, when linking CJTC Dd and Rel-18 eType-II CJT CSI reports is configured with two separate triggers, support to include an indicator in the trigger for a Rel-18 eType-II CJT CSI, which indicates whether the UE should perform delay offset (DO) compensation based on the linked CJTC Dd report when calculating the Rel-18 Type-II CJT CSI or not.

This feature is a separate UE capability
No new DCI field is introduced. This does not preclude increasing the bit width for CSI request.

FFS: Details on signalling design for the indicator including whether it is per CSI-RS resource/Dd value and the associated UE behaviour(s)

Agreement

For the Rel-19 aperiodic standalone CJT calibration (CJTC) reporting, when ReportQuantity is ‘cjtc-P’ (PO) and >1:

· The UCI parameters are captured in the tables below:

Parameter

Details/description

nref

Reference CSI-RS resource index, based on the ordering from RRC configuration: bits

{(_n,, _n,_, _{n,NSB-P}), n=0, 1, …, N_TRP – 1, n≠nref}

DL/UL phase offsets for CSI-RS resource n, (n=0, 1, …, N_TRP – 1, n≠nref):

bits

The UCI mapping order is as follows:

nref,
{(F_n,₀, F_n,_1,..._, F_n,NSB-P_-1), n=0, 1, …, N_TRP – 1, n≠nref} ordered from the lowest to highest CSI-RS resource ID.

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, regarding active resource counting and O_CPU, when ReportQuantity is ‘cjtc-P’ (phase offset), for both =1 and >1, fully reuse those from Rel-18 TDCP reporting

· O_CPU =X.N_TRP where X≥1 is defined based on UE capabilities and determined by the UE

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, when ReportQuantity is ‘cjtc-Dd’ (delay offset), ‘cjtc-F’ (frequency offset), or, ‘cjtc-Dd-F’ (joint delay + frequency offset),

· after the CSI report (re)configuration, serving cell activation, BWP change, the UE reports a CSI report only after receiving at least one CSI-RS transmission occasion for each CSI-RS resource in the CSI-RS Resource Sets of the CSI-RS Resource Setting for channel measurement no later than the CSI reference resource within the same DRX active time, when DRX is configured, and drop the report otherwise

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset),

· after the CSI report (re)configuration, serving cell activation, BWP change, the UE reports a CSI report only after receiving at least one CSI-RS transmission occasion for each of the CSI-RS resources in the corresponding CSI-RS Resource Set for channel measurement no later than the CSI reference resource within the same DRX active time, when DRX is configured, and drop the report otherwise.

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset), regarding the support of sub-band reporting (>1), the maximum value of configured N_SB-P is 16 per CSI reporting setting.

R1-2409061 Moderator Summary for 1st offline on Rel-19 CSI enhancements Moderator (Samsung)

R1-2409058 Moderator Summary#2 on Rel-19 CSI enhancements: Round 2 Moderator (Samsung)

From Tuesday session

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, regarding one-part CSI wideband CQI/PMI reporting, the UCI packing order is as follows:

The wideband CSI for the 1^st reported CRI;
…
The wideband CSI for the M-th reported CRI;

Conclusion

For the Rel-19 aperiodic standalone CJT calibration (CJTC) reporting, when linking CJTC Dd and Rel-18 eType-II CJT CSI reports is configured ~~with a joint trigger~~, there is no consensus in supporting P/SP CSI-RS as the CMR for the Rel-18 eType-II CJT reporting (in addition to the agreed AP CSI-RS).

Agreement

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports, regarding per-layer scaling factor applied to each of the selected SD basis vectors associated with RI=v {2} for the 3-bit scaling factor(s), decide, by RAN1#119, from the following alternatives:

Alt1:
Alt2:
Alt3:
Alt4:
Alt5:
Alt6:
Alt7:

if two different vectors for , for the vector with smaller scaling factor , and for the other vector configured with larger scaling factor ;
otherwise ( or one same vector for ), for the vector

Where r_i denotes the number of layers associated with the i-th SD basis vector.

The same scheme applies to both Mode-A and Mode-B.

Note: as agreed in RAN1#117.

Normalization of precoder should be taken into account in the final specification design.

Agreement

For the Rel-19 Type-I SP codebook refinement for P (the total number of aggregated ports)=48, 64, 128 CSI-RS ports, regarding CPU occupation for the port subset indication for the SD NES Type-1,

	Timeline capability 1	Timeline capability 2
P-report (L subConfigs)
AP/SP-report (N triggered)

R1-2409062 Moderator Summary for 2nd offline on Rel-19 CSI enhancements Moderator (Samsung)

R1-2409059 Moderator Summary#3 on Rel-19 CSI enhancements: Round 3 Moderator (Samsung)

From Wednesday session

Agreement

For the Rel-19 aperiodic standalone CJT calibration (CJTC) reporting, when linking CJTC Dd and Rel-18 eType-II CJT CSI reports is configured with two separate triggers, to indicate whether or not the UE should perform delay offset (DO) compensation based on the latest linked CJTC Dd report when calculating the Rel-18 Type-II CJT CSI, introduce a 1-bit indicator per CSI trigger state:

The 1-bit indicator is an RRC parameter
This is done without increasing the bit-width of the CSI request field of the DCI triggering a Rel-18 CJT eType-II CJT CSI report
FFS (RAN1#119): Whether the 1-bit indicator applies to all the N_TRP CSI-RS resources, or to 1-bit indicator per CSI-RS resource
FFS (RAN1#119): How this applies to a single CSI trigger state associated with >1 CSI reports

Agreement

For the Rel-19 aperiodic standalone CJT calibration (CJTC) reporting, when linking CJTC Dd and Rel-18 eType-II CJT CSI reports is configured with a joint trigger:

Reuse the CPU occupation and active resource counting for the Rel-18 eType-II CJT
FFS (RAN1#119): Re timeline, decide whether to reuse or further relax the timeline for the Rel-18 eType-II CJT

Agreement

For the Rel-19 aperiodic standalone CJT calibration (CJTC) reporting, when linking CJTC Dd and Rel-18 eType-II CJT CSI reports is configured, support linking the CMRs in the two CSI Report Settings so that UE knows which CMRs in the two report settings correspond to the same TRP.

Based on a fixed correspondence between the set of TRS resource set IDs in sequential order and the set of CSI-RS resource IDs in sequential order of configuration in their respective Resource Setting

FFS: linking, when the number of resources configured for CJT CSI is < number of resource sets configured for CJT Dd, in case of separate triggers.

Agreement

For the Rel-19 Type-I SP and Type-II codebook refinements (except based on Rel-18 Type-II Doppler) for 48, 64, and 128 CSI-RS ports, change the maxNumberTxPortsPerResource to maxNumberTxPortsPerReport for Rel-19 codebook triplet capability

Note: Since ARC=1 was agreed, the K aggregated resources are perceived as 1 resource for ARC, and maxNumberTxPortsPerResource cannot be larger than 32.

R1-2409063 Moderator Summary for 3rd offline on Rel-19 CSI enhancements Moderator (Samsung)

R1-2409060 Moderator Summary#4 on Rel-19 CSI enhancements: Round 4 Moderator (Samsung)

From Thursday session

Conclusion

For a UE configured with a total of P_SRS=6 or 8 ports across ≥1 SRS resources for antenna switching intended for xT6R or xT8R, respectively, when SRS port grouping is configured, regarding the mapping between CSI-RS ports and SRS port groups, no additional specification support is introduced

- It is up to gNB implementation to ensure adequate operation of this feature

Thursday decision: The following are withdrawn; postponed to RAN1#119 (Orlando).

R1-2409064 DRAFT LS to RAN2 on RRC and MAC CE impacts for Rel-19 NR MIMO Ph5 Samsung

R1-2409065 LS to RAN2 on RRC and MAC CE impacts for Rel-19 NR MIMO Ph5 RAN1, Samsung

9.2.3 Support for 3-antenna-port codebook-based transmissions

Including support 3T6R SRS antenna switching.

R1-2407680 Discussion on 3-antenna-port UL transmission Huawei, HiSilicon

R1-2407700 Discussion on 3-antenna-port codebook-based transmissions Spreadtrum Communications

R1-2407775 Discussion on 3-antenna-port codebook-based transmissions ZTE Corporation, Sanechips

R1-2407814 3-antenna-port UL transmissions MediaTek Inc.

R1-2407855 Remaining issues on 3-antenna-port codebook-based uplink transmissions vivo

R1-2407899 Discussion on support for 3-antenna-port codebook-based transmissions CMCC

R1-2407963 Discussion on the support of 3-antenna-port CB based transmissions Xiaomi

R1-2407994 Uplink 3 Port Codebook based Transmission Google

R1-2408041 Enhancement for 3-antenna-port UL transmissions CATT

R1-2408110 Discussion on uplink enhancement for UE with 3Tx Fujitsu

R1-2408166 Discussion on 3-antenna-port uplink transmissions OPPO

R1-2408189 Discussion on Rel-19 CB-based UL for 3TX UE InterDigital, Inc.

R1-2408201 Support for 3-antenna-port codebook-based transmissions Lenovo

R1-2408211 Discussion on 3-antenna-port codebook-based transmissions NEC

R1-2408293 Support for 3Tx UL MIMO Intel Corporation

R1-2408338 Discussions on 3-antenna-port UE LG Electronics

R1-2408350 Support for 3-antenna-port transmission Sharp

R1-2408459 Views on R19 MIMO 3Tx transmission Apple

R1-2408639 Views on Rel-19 3-antenna-port codebook-based transmissions Samsung

R1-2408740 On the support for 3-antenna-port codebook-based transmissions Nokia

R1-2408768 Support for 3 Tx UL Transmissions Ericsson

R1-2408780 Discussion on support for 3-antenna-port codebook-based transmissions NTT DOCOMO, INC.

R1-2408844 3 Tx UL MIMO transmissions Qualcomm Incorporated

R1-2408191 FL Summary Support for 3TX CB-based Uplink; First Round Moderator (InterDigital, Inc.)

From Monday session

Agreement

To support 3T6R antenna switching for a 3TX UE,

The resourceType for a configured SRS resource set can be one of ‘periodic’, ‘semi-persistent’ and ‘aperiodic’,
Reuse the principles used for 4T8R, i.e.,

For ~~4T8R~~ 3T6R, zero or one or two SRS resource sets configured with a different value of resourceType in SRS-ResourceSet set to 'periodic' or 'semi-persistent' if the UE is not indicating srs-AntennaSwitching2SP-1Periodic, or up to two SRS resource sets configured with 'semi-persistent' and up to one SRS resource set configured with 'periodic' if the UE is indicating srs-AntennaSwitching2SP-1Periodic, where the two SRS resource sets configured with 'semi-persistent' are not activated at the same time. Each SRS resource set has two SRS resources, transmitted in different symbols, each SRS resource in a given set consisting of a four SRS ports with port 1003 disabled, and the SRS ports of the resource in the set are associated with a different UE antenna ports, or
For ~~4T8R~~ 3T6R, zero or one or two SRS resource sets configured with resourceType in SRS-ResourceSet set to 'aperiodic', where in the case of one resource set has two SRS resources transmitted in different symbols, each SRS resource in a given set consisting of a four SRS ports with port 1003 disabled, and the SRS ports of the resource in the set are associated with a different UE antenna ports. In the case of two resource sets a total of two SRS resources are transmitted in different symbols of two different slots, and where the SRS ports of each SRS resource in the given two sets are associated with a different UE antenna ports.

Note: This is not meant to be a text proposal to be captured for the specifications.

R1-2408192 FL Summary Support for 3TX CB-based Uplink; Second Round Moderator (InterDigital, Inc.)

From Wednesday session

Agreement

To support non-codebook-based PUSCH transmission by a 3TX UE,

- UE reports a capability of up to a maximum of 3 layers.

Conclusion

To support non-codebook-based precoding by a 3TX UE, for SRI indication, re-use the legacy-based solution according to N_SRS ≤ maxNumberSRS-ResourcePerSet.

From Friday session

Conclusion

To support non-codebook-based PUSCH transmission by a 3TX UE,

· For sTRP, a single SRS resource set, with up to N_SRS≤ maxNumberSRS-ResourcePerSet single-port SRS resources, can be configured,

· For Rel-17 M-TRP PUSCH repetition, two SRS resource sets, each with up to N_SRS≤ maxNumberSRS-ResourcePerSet single-port SRS resources, can be configured.

Final summary in R1-2408193.

9.2.44 Enhancement for asymmetric DL sTRP/UL mTRP scenarios

Including support for 2TA without CoresetPoolIdx association for asymmetric DL sTRP/UL mTRP.

R1-2407681 Enhancements for asymmetric DL sTRP/UL mTRP scenarios Huawei, HiSilicon

R1-2407701 Enhancements for asymmetric DL sTRP/UL mTRP scenarios Spreadtrum Communications

R1-2407729 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios China Telecom, ZTE

R1-2407756 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Tejas Network Limited

R1-2407776 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios ZTE Corporation, Sanechips, China Telecom

R1-2407815 Asymmetric DL sTRP/UL mTRP deployments MediaTek Inc.

R1-2407821 Discussion on asymmetric DL sTRP/UL mTRP scenarios TCL

R1-2407856 Remaining issues on asymmetric DL sTRP/UL mTRP scenarios vivo

R1-2407900 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios CMCC

R1-2407964 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios Xiaomi

R1-2408042 Enhancement for asymmetric DL sTRP/UL mTRP scenarios CATT

R1-2408111 Discussion on UL-only mTRP operation Fujitsu

R1-2408118 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios Transsion Holdings

R1-2408167 Enhancements on asymmetric DL sTRP/UL mTRP scenarios OPPO

R1-2408190 Discussion on Rel-19 Asymmetric mTRP Operation InterDigital, Inc.

R1-2408202 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Lenovo

R1-2408224 Discussion on enhancements for asymmetric DL sTRP and UL mTRP scenarios NEC

R1-2408294 Enhancements for asymmetric DL/UL scenarios Intel Corporation

R1-2408339 Discussions on asymmetric DL sTRP/UL mTRP scenarios LG Electronics

R1-2408351 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Sharp

R1-2408369 Discussion on enhancement for asymmetric DL sTRP and UL mTRP scenarios Google

R1-2408406 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Sony

R1-2408460 Enhancements for asymmetric DL sTRP/UL mTRP Apple

R1-2408564 Discussion on UL enhancement in asymmetric TRP scenarios ETRI

R1-2408584 Enhancement for asymmetric DL sTRP UL mTRP scenarios Ericsson

R1-2408640 Views on Rel-19 asymmetric DL sTRP/UL mTRP scenarios Samsung

R1-2408741 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Nokia

R1-2408781 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios NTT DOCOMO, INC.

R1-2408845 Enhancement for asymmetric DL sTRP and UL mTRP deployment scenarios Qualcomm Incorporated

R1-2408891 Discussion on asymmetric DL sTRP and UL mTRP ASUSTeK

R1-2408995 Summary #1 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

From Monday session

Agreement

· The lower limit of the value range of PL offset is extended to -12 dB.

R1-2408996 Summary #2 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

From Tuesday session

Agreement

Support 2TA for the asymmetric DL sTRP/UL mTRP deployment scenarios:

Remove the restriction that coresetPoolIndex needs to be configured for the 2TA feature.
One downlink reference timing is supported and applied to both TAGs.

(FFS) Note: UE autonomous TA adjustment is only applicable to the first TAG

One single n-TimingAdvanceoffset is configured and applied to both TAGs.
Any of the TCI states can be associated with any one of the two TAGs.
The RAR carrying TA adjustment for those 2 TAGs is reused for Rel-19 2TA
The MAC CE based TA adjustment for 2 TAGs is reused for Rel-19 2TA.
Introduce the optional UE capability of “Overlapping UL transmission reduction” for Rel-19 2TA

If UE does not report this UE capability, UE does not expect two UL transmissions associated with different TAGs are overlapped.

FFS: UE does not expect that in intra-slot TDM PUSCH type-B repetition transmission, two consecutive repetitions associated with different TAGs are overlapped.

Agreement

For indicating PL offset for PDCCH-order PRACH, introduce a new 1-bit DCI field in DCI format 1_0:

This DCI field exists when the corresponding RRC parameter (which is a new RRC used to configure the presence of this 1-bit DCI field) is enabled and at least one TCI state is configured with PL offset.
When one joint/UL TCI state is indicated in Rel-17 unified TCI,

the bit field index 0 of this field indicates that PL offset is not included in the PRACH transmission power calculation
the bit field index 1 of this field indicates that the PL offset associated with the indicated TCI state is included in the PRACH transmission power.

FFS: Whether the bit field can be used to indicate other information
FFS: When two joint/UL TCI states are indicated in Rel-18 unified TCI

R1-2408997 Summary #3 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

From Wednesday session

Agreement

For indicating PL offset for PDCCH-order PRACH, when two joint/UL TCI states are indicated in Rel-18 unified TCI, down-select one from the following Alts for the 1-bit DCI field in DCI 1_0 which indicates the application of PL offset on PRACH transmission:

Alt2:

the bit field index 0 of this field indicates that the PL offset associated in the first indicated joint/UL TCI state is included in the PRACH transmission power calculation
the bit field index 1 of this field indicates that the PL offset associated in the second indicated joint/UL TCI state is included in the PRACH transmission power calculation.
FFS: Whether a restriction that only one of the indicated joint/UL TCI states can be configured with PL offset is needed.

FFS: If other information can be indicated by this same 1-bit DCI field for the PDCCH-order PRACH transmission

R1-2409254 Summary #4 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

From Thursday session

Agreement

About the extended value range 1~X of starting bit of blocks in DCI format 2_3 in Rel-19, support Alt1:

Alt1: X = 45 (to be captured in RAN2 spec)

This feature is a separate UE capability and is appliable to any Rel-19 UE who supports this UE capability, regardless this UE supports two separate SRS CLPC adjustment states or not.
Note: X=45 can be used for operations in FR1 in shared spectrum or FR2-2 and X = 43 otherwise

Agreement

Support DCI format 1_1 to indicate TPC command for SRS CLPC adjustment state(s) separate from PUSCH:

(Working Assumption) Introduce a 2-bit TPC command field to indicate TPC command for SRS associated with separate SRS CLPC adjustment state where:

The 2-bit TPC command field is present if UE reports supporting a dedicated UE capability, and a corresponding RRC parameter is configured (which is a new RRC to enable this).

(Working Assumption) Introduce a 1-bit SRS close-loop indicator to indicate one of the two separate SRS CLPC adjustment states for the TPC command.

The 1-bit SRS close-loop indicator is present if UE reports supporting another dedicated UE capability and a corresponding RRC parameter is configured (which is a new RRC to enable this) and two separate SRS CLPC adjustment states are configured.

RAN1#119

9.2 NR MIMO Phase 5

Please refer to RP-242394 for detailed scope of the WI.

[119-R19-MIMO] – Eko (Samsung)

Email discussion on Rel-19 MIMO Phase 5

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2409592 List of RRC and MAC CE impact for Rel-19 MIMO Ph5 Samsung (Moderator)

From Thursday session

R1-2410757 DRAFT LS to RAN2 on RRC and MAC CE impacts for Rel-19 NR MIMO Ph5 Moderator (Samsung)

Decision: The LS to RAN2 on RRC and MAC CE impacts is endorsed. Final LS is approved in R1-2410758.

9.2.1 Enhancements for UE-initiated/event-driven beam management

R1-2409370 Enhancements for UE-initiated/event-driven beam management MediaTek Inc.

R1-2409377 Discussion on enhancements for UE-initiated/event-driven beam management ZTE Corporation, Sanechips

R1-2409427 On UE initiated/event-driven beam management Huawei, HiSilicon

R1-2409459 Further Details on Rel-19 UE/Event-Driven Beam Management InterDigital, Inc.

R1-2409504 Discussion on enhancements for UE-initiated/event-driven beam management CMCC

R1-2409563 Remaining issues for UE-initiated beam management Ericsson

R1-2409586 Views on Rel-19 UE-initiated/event-driven beam management Samsung

R1-2409629 Discussion on UE-initiated/event-driven beam management Spreadtrum, UNISOC

R1-2409673 Remaining issues on UE-initiated/event-driven beam management vivo

R1-2409710 Discussion on UE-initiated/event-driven beam management TCL

R1-2409748 Enhancements for Event-driven Beam Management Intel Corporation

R1-2409792 Enhancements for UE-initiated beam management Apple

R1-2409842 Discussion on enhancements for UE-initiated/event-driven beam management Ruijie Networks Co. Ltd

R1-2409857 Discussion on enhancements for UE-initiated or event-driven beam management NEC

R1-2409888 Discussion on enhancements for UE-initiated/event-driven beam management Xiaomi

R1-2409933 Views on Rel-19 UE-initiated/event-driven beam management CATT

R1-2409961 Enhancements for UE-initiated/event-driven beam management Transsion Holdings

R1-2409969 Enhancements for UE-initiated/event-driven beam management Lenovo

R1-2410035 Enhancements for UE-initiated/event-driven beam management FUTUREWEI

R1-2410053 Discussion on enhancements for UE-initiated/event-driven beam management Fujitsu

R1-2410108 Discussions on UE-initiated/event-driven beam management OPPO

R1-2410116 Offline summary for Rel-19 MIMO UEIBM (9.2.1) pre-RAN1#119 Moderator (ZTE)

R1-2410164 Discussion on enhancements for UE-initiated or event-driven beam management Google

R1-2410171 Discussion on enhancements for UE-initiated/event-driven beam management Hyundai Motor Company

R1-2410175 Discussion on the UE-initiated/event-driven beam management HONOR

R1-2410197 UE-initiated beam management LG Electronics

R1-2410219 Enhancements for UE-initiated/event-driven beam management Sony

R1-2410262 Enhancements for UE-initiated/event-driven beam management ETRI

R1-2410315 Enhancements to facilitate UE-initiated/event-driven beam management Nokia

R1-2410346 Enhancements for UE Initiated Beam Management Meta

R1-2410381 Discussion on enhancements for UE-initiated/event-driven beam management NTT DOCOMO, INC.

R1-2410427 Discussion on UE-initiated/event-driven beam management ITRI

R1-2410435 Enhancements for UE-initiated/event-driven beam management Sharp

R1-2410471 UE-initiated/event-driven beam management Qualcomm Incorporated

R1-2410533 Enhancements for UE-initiated/Event-Driven Beam Management Panasonic

R1-2410538 Discussion on UE initiated beam report ASUSTeK

R1-2410540 Discussions on enhancements for UE-initiated/event-driven beam management KDDI Corporation

R1-2410573 Enhancements for UEiBM CEWiT

R1-2410585 Discussion on enhancements for UE-initiated/event-driven beam management NICT

From Monday session

R1-2410117 Moderator Summary #1 on UE-initiated/event-driven beam management Moderator (ZTE)

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, for the case the pre-configured Type-1 CG PUSCH does NOT carry the beam report, for the second UL channel in Mode-B, Option-2 is supported:

· Option-2: Type-1 CG PUSCH can NOT be transmitted

Agreement

On cross-CC beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Event-2, the following is supported

· the first PUCCH and the second PUSCH associated for UE-initiated/event-driven beam reporting are from the same PUCCH group.

· (working assumption) the first PUCCH and the second PUSCH associated for UE-initiated/event-driven beam reporting are from different PUCCH groups

o Subject to separate UE capability

Conclusion

On cross-CC beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Event-2, the case that the first PUCCH and the second PUSCH are from the different CG is NOT supported.

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding first PUCCH channel configuration, down-select one of Alt-1 and Alt-2 for both mode-A and mode-B.

Alt-1 (dedicated SR): Introduce RRC parameter, e.g., reportResourceRequest-UEIBR/reportNotification-UEIBR, corresponding to the one-bit indication in the first PUCCH channel

The RRC parameter is associated with the dedicated SchedulingRequestId.

Note: The detailed signaling is up to RAN2.

FFS: whether/how to enhance legacy SR to support notification of beam report transmission in Mode-B

Alt-2 (new UCI type): Introduce RRC parameter, e.g., firstPUCCHResourceConfig- UEIBR, for the periodic PUCCH resource configuration.

Note: The RRC parameter is NOT associated with SchedulingRequestId.
1-bit to PUCCH resource is encoded by reusing the encoding mechanism of positive/negative SR.
The dedicated RRC parameter at least comprises the following:

periodicityAndOffset
PUCCH-ResourceID

Above applies at least for the single CC case.
Reuse multiplexing/dropping rule(s) of SR as baseline

FFS: overlapping with SR/LRR or PUSCH

Note: Further details on first PUCCH retransmission for mode A and mode B will be separately discussed.

R1-2410118 Moderator Summary #2 on UE-initiated/event-driven beam management Moderator (ZTE)

From Tuesday session

Agreement

On UE-initiated/event-driven beam reporting, for Event 7, the scheme-1 and scheme-2 for deriving ‘RS for current beam’ on Event-2 is reused with the following further interpretation:

· Scheme-1: ‘RS for current beam’ is the QCL RS in the activated TCI state with the Q-th best quality.

· Scheme-2: ‘RS for current beam’ is the SSB which is QCLed with the QCL RS in the activated TCI state with the Q-th best quality.

· Basic feature of the triggering event determination for Event-7: Once quality of at least one new beam becomes a threshold value better than the RS derived from the activated TCI state with the Q-th best quality, UE initiated beam report occurs

Note: For Event-2, we have the following definition for scheme-1 and scheme-2

· Scheme-1: RS for current beam is the QCL RS in the indicated TCI state

· Scheme-2: RS for current beam is the SSB which is QCLed with the QCL RS in the indicated TCI state.

Agreement

On UE-initiated/event-driven beam reporting, for Event 1, down-select at least one among the following options for RS measurement

· Option-1: RS resource set for new beam is NOT configured in the CSI reporting configuration, and an explicit RRC selection for scheme-1 and scheme-2 is introduced.

· Option-2: RS resource set for new beam is configured in the CSI reporting configuration, and the following implicit manner for enabling one of either scheme-1 or scheme-2 is used:

· If the RS(s) for new beam are CSI-RS configured in a CSI-RS resource set configured with repetition, Scheme-1 is enabled; otherwise, Scheme-2 is enabled.

R1-2410119 Moderator Summary #3 on UE-initiated/event-driven beam management Moderator (ZTE)

From Wednesday session

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding first PUCCH channel configuration, Alt-2 is supported for both mode-A and mode-B: the first PUCCH channel is a new UCI type

Alt-2 (new UCI type): Introduce RRC parameter, e.g., firstPUCCHResourceConfig- UEIBR, for the periodic PUCCH resource configuration.

It is RAN1’s understanding that the RRC parameter is NOT associated with SchedulingRequestId.
1-bit to PUCCH resource is encoded by reusing the encoding mechanism of positive/negative SR.
The dedicated RRC parameter at least comprises the following:

periodicityAndOffset
PUCCH-ResourceID

Above applies at least for the single CC case.
Reuse multiplexing/dropping rule(s) of SR as baseline

FFS: overlapping with SR/LRR or PUSCH

Note: Further details on first PUCCH retransmission (if supported) for mode A and mode B will be continue to be separately discussed in RAN1.

Agreement

Confirm the following working assumption in RAN1#117:

On beam report transmission procedure for UE-initiated/event-driven beam reporting

· For mode-A, at least support one-bit indication in the first PUCCH channel to request a resource for a second UL channel to carry beam report.

o In such case, a periodic PUCCH resource (with PUCCH format 0/1) is configured by dedicated RRC signaling.

· For mode-B, at least support one-bit indication in the first PUCCH channel to notify a second UL channel to carry beam report.

o In such case, a periodic PUCCH resource (with PUCCH format 0/1) is configured by dedicated RRC signaling.

· FFS: Whether/how to support multi-bit indication in the first PUCCH for mode-A and mode-B, e.g., when multi-event(s) are approved.

· FFS: details on the dedicated RRC signaling

· Above applies at least for the single CC case.

Agreement

On UE-initiated/event-driven beam reporting, at least one of the following is supported as an extension on L1-RSRP report format depending on Event-2.

· Option-1: For each of reported CRI/SSBRI, to introduce additional indication of whether the CRI/SSBRI satisfies the condition of Event-2.

o The presence of this field is enabled by RRC with subjective to UE capability.

o The presence of this field is only for the case that N > 1 and the time window and M are configured

· Option-2: For each of reported CRI/SSBRI, to introduce additional indication of the number of Event-2 instances for the CRI/SSBRI(s) within a time window.

o The presence of this field is enabled by RRC with subjective to UE capability.

o The presence of this field is only for the case that N > 1 and the time window and M are configured.

· Option-3: No further enhancement.

Note: As agreed in RAN1#117, at least one of the reported CRI/SSBRI(s) should satisfy the condition of Event-2

FFS: Whether/how to handle the case if UE has not sent any first PUCCH associated for UE-initiated/event-driven beam reporting, for Mode-A.

R1-2410872 Moderator Summary #4 on UE-initiated/event-driven beam management Moderator (ZTE)

From Thursday session

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the triggering procedure in Step-2 of Mode-A, down-select one of the following options in RAN1#120

Option-1: A CSI trigger state is dedicated to UE-initiated/event-driven beam reporting, i.e., not associated with legacy AP-CSI report configuration.
Option-2: A CSI trigger state can be associated with

only UE-initiated/event-driven beam reporting
or only legacy AP-CSI configuration
or UE-initiated/event-driven beam reporting and legacy AP-CSI configuration

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH, further study at least the following cases:

· Case-1: The 1-bit first PUCCH is collided/overlapped with a PUCCH carrying normal SR and/or a PUCCH with normal LRR

· Case-2: The 1-bit first PUCCH is collided/overlapped with a PUSCH

· Case-3: The 1-bit first PUCCHs corresponding to different CSI configuration for UE-initiated/event-driven beam reporting are overlapping in the time domain.

Agreement

Study the following to reduce beam application latency after a UEI/ED beam report is sent

· Alt-1: After confirmation/acknowledgement from NW, apply new beam without RRC configuration signaling or MAC-CE signaling

o after sending a UE-initiated beam report, the UE could store the QCL properties of the SSB associated with the reference signal reported in the beam report

o update TCI state(s) with the reported new beam(s)

o activate new beam(s) without additional SSB reception

· Alt-2: After receiving a TCI state activation command to activate a TCI state(s), if the new beam(s) associated with the TCI state(s) is reported as synchronized in the UEI/ED beam report, the TCI state(s) becomes applicable for DL reception without additional SSB reception.

o Note: A reported new beam is determined as synchronized by UE, if the UE stores the QCL properties associated with the reported new beam(s) after the UEI/ED beam report is sent

o FFS: How to inform a reported new beam in a UEI/ED beam report (i.e., introducing one-bit indicator for each reported new beam or all the reported new beam are assumed to be synchronized)

· Alt-3: After sending a UE-initiated beam report, the UE could store the QCL properties of the SSB associated with the reference signal reported in the beam report.

o In such case, at the reception of a subsequent reception of Unified TCI States Activation/Deactivation MAC CE, the UE activates new beam(s) without additional SSB reception.

· Other alternatives are not precluded.

Agreement

On UE-initiated/event-driven beam reporting, regarding trigger events, the following working assumption in RAN1#118bis is confirmed:

On UE-initiated/event-driven beam reporting, regarding trigger events, besides for Event-2, Event-1 and Event-7 are both supported.

Event-1: Quality of the current beam is worse than a certain threshold.
Event-7: Quality of at least one new beam, such as L1-RSRP, becomes a threshold value better than the RS derived from the activated TCI state with the Q-th best quality.

Q is RRC configured with subjective to UE capability signalling

UE may only indicate a single candidate value or not support Event-7.

The additionally supported events will reuse the same design as event 2 – unless there is consensus to do otherwise
The additionally supported events will be lower priority compared to event 2.

Agreement

Regarding for the evaluation periodicity for determining Event-2 instance [at least when DRX is not configured], at least Alt-1 is supported for the single-CC beam reporting (for case that the CSI report configuration and RS for the current beam and new beam(s) are in the same CC).

· Alt-1: The periodicity of the current beam RS should be the same as that of the new beam RS(s).

o The evaluation periodicity is the same as the periodicity of the current and new beam RS(s).

· Alt-2: The periodicity of the current beam RS can be different from that of the new beam RS(s)

o Alt-2_1: The evaluation periodicity is the same as the periodicity of the current beam RS.

o Alt-2_2: The evaluation periodicity is the same as periodicity of the new beam RS.

o Alt-2_3: The evaluation periodicity is the same as shortest periodicity of the current beam RS and new beam RS(s).

o Alt-2_4: The evaluation periodicity is the maximum of {X ms, shortest periodicity of the current beam RS and new beam RS(s)}.

o Alt-2_5: The evaluation periodicity is the same as largest periodicity of the current beam RS and new beam RS(s).

Note: There is the same periodicity for the new beam RS(s).

FFS: Down-selection among above Alt(s) for cross-CC beam reporting.

Strong concerns were expressed by Huawei and CATT that if only Alt-1 is supported in the end, the feature will not be practical.

Send an LS to RAN4.

From Friday session

R1-2410913 [DRAFT] LS to RAN4 on event-instance evaluation periodicity for UE-initiated/event-driven beam management Moderator (ZTE)

Decision: Draft LS is endorsed and final version is approved in R1-2410914.

9.2.2 CSI enhancements

Including support for up to 128 CSI-RS ports on FR1 and UE reporting enhancement for CJT and SRS port grouping for TDD low-complexity 6/8RX receiver.

R1-2409371 CSI enhancements MediaTek Inc.

R1-2409378 Discussion on CSI enhancements ZTE Corporation, Sanechips

R1-2409428 On 128 CSI-RS ports and UE reporting enhancement Huawei, HiSilicon

R1-2409432 CSI enhancements for Rel. 19 MIMO Fraunhofer IIS, Fraunhofer HHI

R1-2409460 Further Details on Rel-19 Enhancements of CSI InterDigital, Inc.

R1-2409505 Discussion on CSI enhancements CMCC

R1-2409589 Views on Rel-19 CSI enhancements Samsung

R1-2409630 Discussion on CSI enhancements Spreadtrum, UNISOC

R1-2409674 Remaining issues on Rel-19 CSI enhancements vivo

R1-2409747 CSI enhancements for MIMO Intel Corporation

R1-2409761 CSI enhancements Tejas Networks Limited

R1-2409793 Views on R19 MIMO CSI enhancement Apple

R1-2409851 Discussion on CSI enhancements NEC

R1-2409889 Further discussion on Rel-19 MIMO CSI enhancements Xiaomi

R1-2410657 Views on NR MIMO CSI enhancements Phase 5 CATT (rev of R1-2409934)

R1-2409970 Discussion on CSI enhancements Lenovo

R1-2410040 CSI enhancements TCL

R1-2410054 Discussion on Rel-19 CSI enhancements Fujitsu

R1-2410109 CSI enhancements for Rel-19 MIMO OPPO

R1-2410154 CSI Enhancement for NR MIMO Google

R1-2410176 Discussion on CSI enhancements HONOR

R1-2410220 Further views on CSI enhancements Sony

R1-2410303 Discussion on Open Issues of CSI Enhancement Rakuten Mobile, Inc

R1-2410667 CSI enhancement for NR MIMO Phase 5 Nokia (rev of R1-2410316)

R1-2410353 Remaining issues on CSI enhancements for large antenna arrays and CJT Ericsson

R1-2410382 Discussion on CSI enhancements NTT DOCOMO, INC., NTT CORPORATION

R1-2410436 CSI enhancements Sharp

R1-2410472 CSI enhancements for >32 ports and UE-assisted CJT Qualcomm Incorporated

R1-2410549 Discussion on CSI enhancements for NR MIMO Phase 5 KDDI Corporation

R1-2410586 Discussion on CSI enhancements NICT

R1-2409587 Moderator summary for OFFLINE discussion on Rel-19 CSI enhancements Samsung (Moderator)

R1-2409588 Moderator summary on Rel-19 CSI enhancements Samsung (Moderator)

From Monday session

Agreement

For the Rel-19 aperiodic standalone CJT calibration (CJTC) reporting, when linking CJTC Dd and Rel-18 eType-II CJT CSI reports is configured with a joint trigger, the timeline (Z/Z’) is determined as Z/Z’ associated with the Rel-18 eType-II CJT, plus D_relax

The value of D_relax is a UE capability, taken from {0, d_relax}

FFS: The value of d_relax (>0), including whether it depends on SCS

For linking CJTC Dd and Rel-18 eType-II CJT CSI, joint triggering is a separate UE feature group from separate triggering

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, if the UCI associated with each of the M CRIs comprises two parts and is multiplexed on PUCCH, the UE determines the PUCCH resource, the number of PRBs for the PUCCH resource, assuming that the CSI associated with each of the M reported CRIs corresponds to rank 1.

Agreement

For the Rel-19 aperiodic standalone CJT calibration (CJTC) reporting, when linking CJTC Dd and Rel-18 eType-II CJT CSI reports is configured, regarding linking the CMRs in the two CSI Report Settings, for separate triggering, the UE expects that the number of configured CSI-RS resources associated with the Rel-18 eType-II CJT CSI is always the same as the number of TRS resource sets associated with the Rel-19 CJTC Dd report.

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, regarding UCI reported in CSI part-1, if resource-specific RI restriction is configured, zero padding bits are introduced in CSI part 1 for each of the (MM_R) reported CRIs:

· For a k-th CRI from the (MM_R) reported CRIs (where k=1, 2, …, (MM_R)), zero padding bits are inserted where:

§ , where is the size of RI field corresponding to the i-th CRI, and is the set of CRIs corresponding to the (K_sM_R) resources

§ is the size of RI field corresponding to the k-th CRI

Agreement

The scaling formula is where is a multiplicative factor independent of i

Reuse legacy precoder normalization (per discretion of the spec editor)
FFS (RAN1#119): Whether min( , 1) operation is needed
FFS (RAN1#119): Whether other than 1 (baseline) is needed (e.g. or )

Regarding the configuration of the value (3-bit indicator per SD basis vector group), decide, by RAN1#119, between the following:

Alt1. RI=1 and RI=2 are separately configured (RI-specific)
Alt2. A same configuration is used for RI=1 and RI=2 (RI-common)

Conclusion

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, regarding packing order and priority levels of N_Rep CSI reports with M CRIs, the UCI packing order and the consecutive priority levels (higher to lower) follows the legacy specifications.

R1-2410754 Moderator Summary for 1st offline on Rel-19 CSI enhancements Moderator (Samsung)

R1-2410755 Moderator Summary for 2nd offline on Rel-19 CSI enhancements Moderator (Samsung)

R1-2410751 Moderator Summary#2 on Rel-19 CSI enhancements: Round 2 Moderator (Samsung)

From Wednesday session

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, regarding wideband P/SP-CSI reported using one-part CSI, if resource-specific RI restriction is configured, the zero padding bits for each of the M reported CRI are determined as follows:

For a k-th CRI from the M reported CRIs, , where:

, where Q is the set of CRIs corresponding to K_s resources and is the maximum payload size of associated CSI fields for a j-th CRI, and _,where is the set of rank values that are allowed to be reported for the j-th CRI;
, where is the reported rank for k-th CRI;
Note: is the size of RI field corresponding to k-th CRI.
Note: The definition of the operator B(∙) is as legacy (as defined in 38.212).

Note: Here k, j=1, 2, …, K_S

Note: How this is captured in the spec (including exact formulation) is up to the editor(s).

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, regarding aperiodic CSI-RS resource configuration, an RRC-configured resource-level slot offset (relative to the resource-set-level slot offset, using the same design as Rel-19 Type-I/II codebook refinement for 48, 64, and 128 ports) is supported for aperiodic CSI-RS resource set.

FFS: The number of bits for indicating the resource-level slot offset (relative to the resource-set-level slot offset) for K_S resources, including the value(s) of the slot offset.

FFS: Whether, in addition, configuring an available slot offset for each CSI-RS resource within the aperiodic CSI-RS resource set.

Note: “Available slot offset” is analogous to the Rel-17 SRS triggering offset enhancement.

Agreement

For the Rel-19 Type-I SP codebook refinement for P=48, 64, 128 CSI-RS ports, when the UE reports or multiplexes the CSI that include Part 2 CSI reports on PUCCH, the PUCCH resource, the number of PRBs for the PUCCH resource, and/or the number of Part 2 CSI reports are determined based on the RI value that results in the largest UCI payload.

For Scheme-A, the RI value is:

8 when the RI value(s) allowed by the configured RI restriction per CSI reporting configuration include 5, 6, 7, and/or 8,
1 otherwise.

For Scheme-B, the RI value is 4.

Agreement

For the Rel-19 aperiodic standalone CJT calibration (CJTC) reporting, when linking CJTC Dd and Rel-18 eType-II CJT CSI reports is configured with a joint triggering carried on a same PUSCH (hence on a same slot), the UCI associated with the CJTC Dd report is multiplexed in CSI Part 1.

The previously agreed UCI design and mapping order for CJTC Dd report are reused.
The legacy UCI design, UCI mapping order, and UCI omission for the Rel-18 eType-II CJT CSI are reused.

Note: The above proposal reuses the legacy UCI design principles, where the UCI associated with the CJTC Dd is placed in the part of UCI as TS 38212 Table 6.3.1.1.2-13; the CSI part 1 of Rel-18 eType-II CJT CSI is placed in the part of UCI as TS 38.212 Table 6.3.1.1.2-13 and the CSI part 2 of Rel-18 eType-II CJT CSI is placed in the part of UCI as TS 38.212 Table 6.3.1.1.2-14.

Agreement

For the Rel-19 aperiodic standalone CJT calibration (CJTC) reporting, when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset), the UE assumes that the N_TRP CSI-RS resources are transmitted without DL/UL switching in between the N_TRP resources.

Agreement

Note: In this case, the min(s_i,1) operation is not needed.

Agreement

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports, regarding per-layer scaling factor applied to each of the selected SD basis vectors for the 3-bit scaling factor(s), the configuration of the value (3-bit indicator per SD basis vector group) is RI-common (a same configuration is used for RI=1 and RI=2).

Conclusion

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports with the Rel-15 Type-I SP codebook, joint operation with the Rel-18 NES framework is not supported.

R1-2410752 Moderator Summary#3 on Rel-19 CSI enhancements: Round 3 Moderator (Samsung)

R1-2410756 Moderator Summary for 3rd offline on Rel-19 CSI enhancements Moderator (Samsung)

9.2.3 Support for 3-antenna-port codebook-based transmissions

Including support 3T6R SRS antenna switching.

R1-2409372 Enhancements for 3-antenna-port transmissions MediaTek Inc.

R1-2409379 Discussion on 3-antenna-port codebook-based transmissions ZTE Corporation, Sanechips

R1-2409429 Discussion on 3-antenna-port UL transmission Huawei, HiSilicon

R1-2409461 Further Details on Rel-19 CB-based UL for 3TX UE InterDigital, Inc.

R1-2409506 Discussion on support for 3-antenna-port codebook-based transmissions CMCC

R1-2409590 Views on Rel-19 3-antenna-port codebook-based transmissions Samsung

R1-2409675 Remaining issues on 3-antenna-port codebook-based uplink transmissions vivo

R1-2409794 Remaining issues on R19 MIMO 3Tx transmission Apple

R1-2409890 Discussion on the support of 3-antenna-port CB based transmissions Xiaomi

R1-2409935 Views on 3-antenna-port uplink transmissions CATT

R1-2409971 Support for 3-antenna-port codebook-based transmissions Lenovo

R1-2410055 Discussion on uplink enhancement for UE with 3Tx Fujitsu

R1-2410110 Discussion on 3-antenna-port uplink transmissions OPPO

R1-2410155 Uplink 3 Port Codebook based Transmission Google

R1-2410317 On the support for 3-antenna-port codebook-based transmissions Nokia

R1-2410341 Remaining issues for 3 Tx UL transmissions Ericsson

R1-2410383 Discussion on support for 3-antenna-port codebook-based transmissions NTT DOCOMO, INC.

R1-2410437 Support for 3-antenna-port transmission Sharp

R1-2409463 FL Summary Support for 3TX CB-based Uplink; First Round Moderator (InterDigital, Inc.)

From Monday session

Conclusion

To support 3T6R antenna switching for a 3TX UE,

Reuse the power control parameters configuration principles of 4T8R for 3T6R, i.e., when two aperiodic SRS resource sets are configured,

if a UE is provided TCI-State in dl-OrJointTCI-StateList or TCI-UL-State, the UE shall expect that the two SRS resource sets are associated with the same values of the higher layer parameters p0AlphaSetforSRS and pathlossReferenceRS-Id
Otherwise, the UE shall expect that the two SRS resource sets are configured with the same values of the higher layer parameters alpha, p0, pathlossReferenceRS, and srs-PowerControlAdjustmentStates in SRS-ResourceSet.

Agreement

The following capabilities are introduced for Rel-19

· 't3r3' for 3T3R.

· 't3r6' for 3T6R.

From AI 5

R1-2409353 LS on UE RF issues for Rel-19 MIMO enhancement RAN4, Huawei

From Monday session

Agreement

Support the following replies to Questions 2 and 3 in RAN4 LS,

Question 2: RAN4 would like to check with RAN1 whether a 3Tx UE supporting UL full power transmission mode 0 needs to achieve the same maximum output power with both 1Layer and 2Layers.

Question 3: RAN4 would like to check with RAN1 whether 3Tx UE can support UL full power transmission mode 0 with 2Layer 3-port codebooks but not support 1Layer 3-port codebooks.

Reply to Q2: Yes, a 3Tx UE supporting UL full power transmission mode 0, delivers the same maximum output power with both 1- and 2-layer precoders.

Reply to Q3: No, a 3Tx UE supporting UL full power transmission mode 0, shall support full power with both 1- and 2-layer 3-port codebook.

R1-2409464 FL Summary Support for 3TX CB-based Uplink; Second Round Moderator (InterDigital, Inc.)

From Wednesday session

R1-2410762 Draft Reply to RAN4 LS on UE RF issues for Rel-19 MIMO Enhancement InterDigital, OPPO

Decision: The draft LS is endorsed and final version is approved in R1-2410870.

Agreement

For a UE operating with 3TX,

the RRC parameter for enabling a configured 4-port SRS resource with port 1003 disabled, is applied for all SRS resource set(s) for SRS usage set as codebook.
the RRC parameter for enabling a configured 4-port SRS resource with port 1003 disabled, is applied for all SRS resource set(s) for SRS usage set as antenna switching.
Note: The RRC parameter mentioned in the above two bullets is configured per set

A UE does not expect an SRS resource to be configured in both codebook and antenna switching resource sets with conflicting (disabled state) configuration for the port 1003.

Final summary in R1-2409465.

9.2.44 Enhancement for asymmetric DL sTRP/UL mTRP scenarios

Including support for 2TA without CoresetPoolIdx association for asymmetric DL sTRP/UL mTRP.

R1-2409373 Enhancement for asymmetric DL sTRP/UL mTRP scenarios MediaTek Inc.

R1-2409380 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios ZTE Corporation, Sanechips, China Telecom

R1-2409430 Enhancements for asymmetric DL sTRP/UL mTRP scenarios Huawei, HiSilicon

R1-2409462 Further Details on Rel-19 Asymmetric mTRP Operation InterDigital, Inc.

R1-2409507 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios CMCC

R1-2409591 Views on Rel-19 asymmetric DL sTRP/UL mTRP scenarios Samsung

R1-2409631 Enhancements for asymmetric DL sTRP/UL mTRP scenarios Spreadtrum, UNISOC

R1-2409676 Remaining issues on asymmetric DL sTRP/UL mTRP scenarios vivo

R1-2409709 Discussion on asymmetric DL sTRP/UL mTRP scenarios TCL

R1-2409746 Enhancements for asymmetric DL/UL scenarios Intel Corporation

R1-2409762 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Tejas Networks Limited

R1-2409769 Enhancement for asymmetric DL sTRP UL mTRP scenarios Ericsson

R1-2409795 Enhancements for asymmetric DL sTRP/UL mTRP Apple

R1-2409858 Discussion on enhancements for asymmetric DL sTRP and UL mTRP scenarios NEC

R1-2409891 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios Xiaomi

R1-2409936 Views on Rel-19 asymmetric DL sTRP/UL mTRP scenarios CATT

R1-2409962 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios Transsion Holdings

R1-2409972 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Lenovo

R1-2409997 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios China Telecom, ZTE

R1-2410056 Discussion on UL-only mTRP operation Fujitsu

R1-2410111 Enhancements on asymmetric DL sTRP/UL mTRP scenarios OPPO

R1-2410165 Discussion on enhancement for asymmetric DL sTRP and UL mTRP scenarios Google

R1-2410198 Discussions on asymmetric DL sTRP/UL mTRP scenarios LG Electronics

R1-2410221 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Sony

R1-2410263 Discussion on DL single TRP and UL mTRP operation ETRI

R1-2410318 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Nokia

R1-2410384 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios NTT DOCOMO, INC.

R1-2410438 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Sharp

R1-2410473 Enhancement for asymmetric DL sTRP and UL mTRP deployment scenarios Qualcomm Incorporated

R1-2410534 "Enhancement for Asymmetric DL sTRP/UL mTRP Scenarios" Panasonic

R1-2410539 Discussion on asymmetric DL sTRP and UL mTRP ASUSTeK

R1-2410649 Summary #1 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

Presented in Monday session

R1-2410650 Summary #2 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

From Tuesday session

Agreement

Support to apply PL offset on PDCCH-order PRACH in FR2

The design for applying PL offset on PDCCH-order PRACH in FR1 is fully reused here.

Note: there is no extra enhancement for Tx beam determination for PDCCH-order PRACH in FR2 in Rel-19.

Agreement

Support DCI format 1_1 to indicate TPC command for SRS CLPC adjustment state(s) separate from PUSCH:

(Working Assumption) Introduce a 2-bit TPC command field to indicate TPC command for SRS associated with separate SRS CLPC adjustment state where:

The 2-bit TPC command field is present if UE reports supporting a dedicated UE capability, and a corresponding RRC parameter is configured (which is a new RRC to enable this).

(Working Assumption) Introduce a 1-bit SRS close-loop indicator to indicate one of the two separate SRS CLPC adjustment states for the TPC command

The 1-bit SRS close-loop indicator is present if UE reports supporting another dedicated UE capability and a corresponding RRC parameter is configured (which is a new RRC to enable this) and two separate SRS CLPC adjustment states are configured.

Agreement

For a UE supporting the UE capability of “Overlapping UL transmission reduction” of Rel-19 2TA:

The overlapping duration of the latter one of two overlapping UL transmissions is reduced, where the two overlapped UL transmissions are associated with two TAGs.

Agreement

For an SRS resource set not configured with followUnifiedTCI-StateSRS, regarding how to determine the PL offset and the CLPC adjustment state, down-select from the following Alts:

Alt1: The PL offset and CLPC adjustment state indicated by the TCI state configured to the SRS resource with lowest ID (i.e., reusing the rule specified in Rel-17) and no extra enhancement.
Alt2: The PL offset and CLPC adjustment state indicated by the TCI state configured to the SRS resource with lowest ID (i.e., reusing the rule specified in Rel-17), the SRS with lowest ID is always configured with one joint/UL TCI state, the “referenceSignal” in a UL TCI state is optional.
Alt3:

When the SRS resource with lowest ID is configured with a TCI state, The PL offset and CLPC adjustment state indicated by that TCI state are applied to those SRS resources (i.e., reusing the rule specified in Rel-17)
Otherwise, one of the two separate SRS CLPC adjustment states and one PL offset are configured in the SRS resource set, and they are applied on the SRS resources.

Alt4:

When the SRS resource with lowest ID is configured with a TCI state, The PL offset and CLPC adjustment state indicated by that TCI state are applied to those SRS resources (i.e., reusing the rule specified in Rel-17)
Otherwise, one PL offset and one CLPC adjustment state are applied on the SRS resources.

FFS how to define the PL offset and CLPC adjustment state

From AI 5

R1-2409353 LS on UE RF issues for Rel-19 MIMO enhancement RAN4, Huawei

From Tuesday session

(Question 1: RAN4 would like to inquire if the UL TRP(s) can transmit SSBs per the scope of the WID.)

Agreement

The answer to the Question 1 in LS R1-2409353 is:

· From the perspective of UE: if UE is configured with PL offset in joint/UL TCI state(s), UE does not expect to receive SSB from UL TRP(s), else, UE may expect to receive SSB from UL TRP(s).

See final reply LS in R1-2410870.

Final summary in R1-2410651.

RAN1#120

9.2 NR MIMO Phase 5

Please refer to RP-242394 for detailed scope of the WI. Additional RAN guidance on Rel-19 NR MIMO can be found in RP-243265.

Rapporteur to provide initial input on higher layer signalling under agenda item 9.2. For input on higher layer signalling from any other source, please include it as part of your tdoc to relevant sub-agenda items.

[120-R19-MIMO] – Gilwon (Samsung)

Email discussion on Rel-19 MIMO Phase 5

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2500844 List of RRC impact for Rel-19 MIMO Ph5 Moderator (Samsung)

R1-2500845 Draft LS to RAN2 on MAC impact for Rel-19 MIMO Ph5 Samsung, MediaTek

From Thursday session

Agreement

LS to RAN2 on MAC impacts for Rel-19 NR MIMO Ph5 is endorsed. Final LS is approved in R1-2500846.

9.2.1 Enhancements for UE-initiated/event-driven beam management

R1-2500056 Enhancements for UE-initiated/event-driven beam management FUTUREWEI

R1-2500097 On UE initiated/event-driven beam management Huawei, HiSilicon

R1-2500104 Enhancements for UE-initiated/event-driven beam management MediaTek Inc.

R1-2500115 Remaining Details on Rel-19 UE/Event-Driven Beam Management InterDigital, Inc.

R1-2500163 Discussion on UE-initiated/event-driven beam management Spreadtrum, UNISOC

R1-2500217 Views on enhancement for Rel-19 UE-initiated/event-driven beam management CATT

R1-2500240 Discussion on UE-initiated/event-driven beam management TCL

R1-2500241 Discussion on enhancements for UE-initiated/event-driven beam management ZTE Corporation, Sanechips

R1-2500279 Discussion on enhancements for UE-initiated/event-driven beam management CMCC

R1-2500342 Remaining issues on UE-initiated/event-driven beam management vivo

R1-2500377 Discussions on UE-initiated/event-driven beam management China Telecom Corporation Ltd.

R1-2500470 Discussions on UE-initiated/event-driven beam management OPPO

R1-2500513 On UE-initiated/event-driven beam management Ofinno

R1-2500569 UE-initiated beam management LG Electronics

R1-2500592 Discussion on enhancements for UE-initiated or event-driven beam management NEC

R1-2500645 Enhancements for UE-initiated/event-driven beam management Sony

R1-2500671 Discussion on enhancements for UE-initiated/event-driven beam management Ruijie Networks Co. Ltd

R1-2500699 Enhancements for UE-initiated/event-driven beam management Lenovo

R1-2500725 Discussion on enhancements for UE-initiated/event-driven beam management Xiaomi

R1-2500771 Remaining issues for UE-initiated beam management Apple

R1-2500839 Views on Rel-19 UE-initiated/event-driven beam management Samsung

R1-2500896 Enhancements to facilitate UE-initiated/event-driven beam management Nokia

R1-2500905 Enhancements for UE-initiated/event-driven beam management ETRI

R1-2500930 Discussion on enhancements for UE-initiated/event-driven beam management Fujitsu

R1-2500963 Enhancements for UE-initiated/event-driven beam management Transsion Holdings

R1-2500977 Enhancements for UE-initiated/Event-Driven Beam Management Panasonic

R1-2501084 Enhancements for UE Initiated Beam Management Meta

R1-2501087 Discussion on enhancements for UE-initiated/event-driven beam management Hyundai Motor Company

R1-2501105 Discussion on the UE-initiated/event-driven beam management HONOR

R1-2501127 Enhancements for UE-initiated/event-driven beam management Sharp

R1-2501149 UE-initiated/event-driven beam management Qualcomm Incorporated

R1-2501195 Discussion on enhancements for UE-initiated/event-driven beam management NTT DOCOMO, INC.

R1-2501230 Discussion on UE-initiated/event-driven beam management ITRI

R1-2501236 Discussion on UE initiated beam report ASUSTeK

R1-2501245 Remaining issues for UE-initiated beam management Ericsson

R1-2501264 Enhancements for UE-initiated/event-driven beam management KT Corp.

R1-2501309 Discussion on enhancements for UE-initiated/event-driven beam management NICT

R1-2501334 Discussion on enhancements for UE-initiated or event-driven beam management Google

R1-2501341 Discussions on enhancements for UE-initiated/event-driven beam management KDDI Corporation

R1-2500942 Offline summary for Rel-19 MIMO UEIBM (9.2.1) pre-RAN1#120 Moderator (ZTE)

R1-2500943 Moderator Summary #1 on UE-initiated/event-driven beam management Moderator (ZTE)

From Monday session

Agreement

On cross-CC beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Event-2, the following working assumption is confirmed with the following modification.

· The first PUCCH and the second PUSCH associated for UE-initiated/event-driven beam reporting are from different PUCCH groups

o Subject to separate UE capability

· Note: From RAN1 perspective, the above does NOT introduce any spec impact except for UE capability signaling

Agreement

On cross-CC beam report measurement for UE-initiated/event-driven beam reporting, regarding Event-2, the following is supported

The current beam RS and new beam RS(s) are in the same CC

The above does NOT imply to preclude the cross-CC TCI indication.

The CC on which the indicated TCI state is applied, and the CC in which new beam RS(s) are can be the same or different.

FFS: Whether/how to introduce an RRC parameter to indicate the CC on which the indicated TCI state is applied.

Agreement

On UE-initiated/event-driven beam reporting, for Event 7, the candidate value of RRC parameter Q = {1, 2, 3, 4, 5, 6, 7, 8}

· Note: The UE does not expect that the configured Q is greater than the number of the activated DL/joint TCI state(s).

Conclusion

There is no RAN1 consensus on the following proposal:

· On beam report transmission procedure for UE-initiated/event-driven beam reporting, multi-bit indication in the first PUCCH is supported.

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Mode-B, the value of X symbols for determining available transmission occasion of the second UL channel is configured by RRC (FFS: subject to a corresponding UE capability).

R1-2500944 Moderator Summary #2 on UE-initiated/event-driven beam management Moderator (ZTE)

From Tuesday session

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, support the following option of dropping rule for the Case-1: the 1-bit first PUCCH is collided/overlapped with a PUCCH carrying normal SR and/or a PUCCH with normal LRR

· Option-1: LRR > first PUCCH > normal SR

Note: When the 1-bit first PUCCH is collided/overlapped with a PUCCH carrying normal SR and/or a PUCCH with normal LRR, only one of them is transmitted based on the above priority rule

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the triggering procedure in Step-2 of Mode-A, the following Option-1 is supported.

· Option-1: A CSI trigger state corresponding to UE-initiated/event-driven beam reporting can NOT be associated with legacy AP-CSI report configuration.

Agreement

Regarding triggering event determination for Event 2, at least Candidate #2 is supported for resetting the counting.

· Candidate#1: RS reconfiguration/update or MAC-CE signaling (if supported) for new beam is received;

o FFS: whether to reset the counting for all new beams.

o FFS: whether to maintain the counting whose new beam is NOT updated.

· Candidate#2: [The measured current beam based on] indicated TCI state is updated;

o In such case, the UE need to reset the counting for all new beams.

· Candidate#3: UEI beam report is transmitted;

o FFS: Only reset the counting of new beams fulfilling triggering condition and reported by the UEI beam report

· Candidate#4: NW response (e.g., DCI in step-2 of Mode-A) is detected.

· Candidate#5: The time window expires

· Candidate#6: The threshold for event evaluation is re-configured by RRC signaling

· (FFS) Candidate#7: The RRC parameter(s) associated with the CSI report configuration for UEI beam report is reconfigured.

o FFS: RRC parameter(s)

· FFS: Other candidates

Note: Whether this proposal is captured in RAN1 or RAN2 is a separate discussion point.

R1-2500945 Moderator Summary #3 on UE-initiated/event-driven beam management Moderator (ZTE)

From Wednesday session

Agreement

On UE-initiated/event-driven beam reporting, for Event 1, support Option-2 for RS measurement:

Option-2: RS resource set for new beam is configured in the CSI reporting configuration, and the following implicit manner for enabling one of either scheme-1 or scheme-2 is used:

If the RS(s) for new beam are CSI-RS configured in a CSI-RS resource set configured with repetition, Scheme-1 is enabled; otherwise, Scheme-2 is enabled.
In such case, the report format for Event-2 is reused unless critical technical issue is identified

FFS: How to report the RSRP value of the current beam
FFS: RSRP of the current beam is always reported

Agreement

Regarding triggering event determination for Event 2, on the measurement window for initiating the UE-initiated/event-driven beam reporting procedure, further study the following options for possible down-selection

Option-1: The measurement window is from T_PUCCH – T_proc – T_window to T_PUCCH – T_proc, where T_PUCCH is a transmission occasion of a first PUCCH, and T_proc is RRC configured.
Option-2: The measurement window is from T_Instance – T_window to T_Instance, where T_Instance is an evaluation occasion of event instance, and T_proc is RRC configured.

The UEI beam report in the second PUSCH is based on the most recent measurement for new/current beam RS(s).

Option-3: The length, slot offset and periodicity of a measurement window are configured per CSI report configuration by NW.
Option-4: If an Event-2 instance for a new beam is obtained at the time , UE (re)starts the timer for the new beam, where the expiry time of the timer is equal to the NW-configured length of the time window (T_window)
Note: T_window is the agreed time window parameter for measurement.
Note: Other options are not precluded.

R1-2501556 Moderator Summary #4 on UE-initiated/event-driven beam management Moderator (ZTE)

From Thursday session

Agreement

On UE-initiated/event-driven beam reporting, Option-1 is supported as an extension on L1-RSRP report format depending on Event-2.

Option-1: For each of reported CRI/SSBRI, to introduce additional indication of whether the CRI/SSBRI satisfies the condition of Event-2.

The presence of this field is enabled by RRC with subjective to UE capability.
Note: The presence of this field is only for the case that N > 1 and the time window and M are configured

Above is NOT applicable for event 1.

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, one PUCCH resource of first PUCCH can be associated with one or multiple CSI report configurations, regarding Event-2.

Only a single UEI beam report is carried in the second PUSCH.

Additional indication of one ‘CSI report configuration’ is provided in the report format.

The CSI report configurations associated with the same PUCCH resource are ordered in ascending order of corresponding CSI-ReportConfigId, the number of bits of the additional indication field is ceil(log₂(N_CSIconfig)), where the N_CSIconfig denotes the number of CSI report configurations associated with the same PUCCH resource.

The payload size of the single UEI beam report is determined according to the max payload size among the associated CSI report configurations.

Zero-padding can be appended if the payload size of the UEI beam report is less than the max report payload.

The reported UEI beam report should satisfy the triggering condition.
If multiple UE initiated beam report procedures occur, down-select one of the following options:

Option-1: It is up to UE implementation to select one of configuration.
Option-2: The UEI beam report with highest priority is reported
Option-3: The report triggered in the latest measurement is reported in PUSCH

The multiple CSI report configurations associated with the one first PUCCH resource should be configured in the same CC.
Working Assumption: For Mode-A, the multiple CSI report configurations associated with the same PUCCH resource should be associated with a same CSI-AperiodicTriggerState.
For Mode-B, the multiple CSI report configurations associated with the same PUCCH resource should be associated with the same second configured PUSCH

FFS: Alt-2 Multiple UEI beam reports associated with the same PUCCH resource for first PUCCH can be transmitted in the second PUSCH.

· If RAN1 cannot converge on the support of Alt-2 in RAN1#120bis, this alternative will be dropped from Rel-19

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH, down-select one of the following rule for the Case-2: the 1-bit first PUCCH is collided/overlapped with a PUSCH

Option-1: Prioritize first PUCCH over PUSCH, i.e., PUSCH is dropped.
Option-3: Piggyback 1-bit indication of first PUCCH into the PUSCH.

FFS: If the PUSCH should be with UL-SCH or not for UEI beam report

Option-4: Reuse the SR dropping rules, i.e., the first PUCCH is dropped.
FFS: whether/how to handle the case of different PHY priorities.

9.2.2 CSI enhancements

Including support for up to 128 CSI-RS ports on FR1 and UE reporting enhancement for CJT and SRS port grouping for TDD low-complexity 6/8RX receiver.

R1-2500098 On 128 CSI-RS ports and UE reporting enhancement Huawei, HiSilicon

R1-2500105 CSI enhancements MediaTek Inc.

R1-2500116 Remaining Details on Rel-19 Enhancements of CSI InterDigital, Inc.

R1-2500164 Discussion on CSI enhancements Spreadtrum, UNISOC

R1-2500218 Discussion on CSI enhancements for NR MIMO Phase 5 CATT

R1-2500242 Discussion on CSI enhancements ZTE Corporation, Sanechips

R1-2500280 Discussion on CSI enhancements CMCC

R1-2500343 Remaining issues on Rel-19 CSI enhancements vivo

R1-2500471 CSI enhancements for Rel-19 MIMO OPPO

R1-2500484 Discussion on Rel-19 CSI Enhancements Tejas Network Limited

R1-2500485 CSI enhancements for Rel. 19 MIMO Fraunhofer IIS, Fraunhofer HHI

R1-2500550 CSI Enhancement for NR MIMO Google

R1-2500598 Discussion on CSI enhancements NEC

R1-2500646 Discussion of CSI enhancements Sony

R1-2500700 Discussion on CSI enhancements Lenovo

R1-2500726 Further discussion on Rel-19 MIMO CSI enhancements Xiaomi

R1-2500772 Views on R19 MIMO CSI enhancement Apple

R1-2500841 Views on Rel-19 CSI enhancements Samsung

R1-2500897 CSI enhancement for NR MIMO Phase 5 Nokia

R1-2500906 Discussion on CSI enhancements for NR MIMO Phase 5 ETRI

R1-2500931 Remaining issues on Rel-19 CSI enhancements Fujitsu

R1-2501073 Discussion on Open Issues of CSI Enhancement Rakuten Mobile, Inc

R1-2501106 Discussion on CSI enhancements HONOR

R1-2501128 CSI enhancements Sharp

R1-2501150 CSI enhancements for >32 ports and UE-assisted CJT Qualcomm Incorporated

R1-2501196 Discussion on CSI enhancements NTT DOCOMO, INC., NTT CORPORATION

R1-2501272 Remaining issues on CSI enhancements for large antenna arrays and CJT Ericsson

R1-2501297 Discussion on CSI enhancements for NR MIMO Phase 5 KDDI Corporation

R1-2501307 Discussion on CSI enhancements NICT

R1-2500840 Moderator Summary#1 on Rel-19 CSI enhancements: Round 1 Moderator (Samsung)

From Monday session

Conclusion

For the Rel-19 aperiodic standalone CJT calibration (CJTC) reporting, when linking CJTC Dd and Rel-18 eType-II CJT CSI reports is configured with a joint trigger, regarding timeline, the value of d_relax will be decided in UE feature session.

Note: Per previous agreement, only a single non-zero value of D_relax=d_relax is supported, in addition to the already agreed D_relax=0.

Agreement

For the Rel-19 aperiodic standalone CJT calibration reporting, when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset), regarding the support of sub-band reporting (>1),

The legacy CSI sub-band definition and partitioning rules are reused.

Agreement

For the Rel-19 Type-I SP codebook refinement for P=48, 64, 128 CSI-RS ports, regarding Scheme-B, when the UE is configured to report wideband CSI on PUCCH:

For PUCCH format 2, one-part CSI is used
For PUCCH formats 3 and 4, decide, by RAN1#120, between the two alternatives:

Alt1 (baseline). One-part CSI is used
Alt2. Two-part CSI is used where SD basis selection is reported in CSI-part2

CSI fields in CSI-part1 and part2 follows the legacy sub-band CSI

Agreement

For the Rel-19 Type-I SP codebook refinement for P=48, 64, and 128 CSI-RS ports, regarding the CSI reference resource

For P=128 with Capability 2 timeline, when periodic or semi-persistent CSI reporting is configured, decide (by RAN1#120) between the two alternatives:

Alt1. n_{CSI_ref} follows legacy specification.
Alt2. scale n_{CSI_ref} from the legacy specification by ceil(P/32).

For all other cases, n_{CSI_ref} follows legacy specification to determine the CSI reference resource for periodic or semi-persistent CSI reporting.

Conclusion

For the Rel-19 Type-II codebook refinement based on Rel-18 Type-II Doppler for 48, 64, and 128 CSI-RS ports, whether to change the maxNumberTxPortsPerResource to maxNumberTxPortsPerResourceGroup for Rel-19 codebook triplet capability is to be discussed in UE feature session.

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, regarding the value of the RRC-configured resource-level slot offset (relative to the resource-set-level slot offset) for aperiodic CSI-RS resource set, at least the following values are supported: {0, 1, 2, 3}

FFS: Whether to also support {4, 5, …, X-1} where X is either 8, 16, or 32 for only Type-II or all applicable codebooks.
Note: For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, the RRC-configured resource-level slot offset (relative to the resource-set-level slot offset) for aperiodic CSI-RS resource set does not apply to CSI-RS for tracking.

R1-2501362 Moderator Summary for 1st offline on Rel-19 CSI enhancements Moderator (Samsung)

R1-2501361 Moderator Summary#2 on Rel-19 CSI enhancements: Round 2 Moderator (Samsung)

From Wednesday session

Agreement

For the Rel-19 Type-I SP codebook refinement for P=48, 64, 128 CSI-RS ports, regarding Scheme-B, when the UE is configured to report wideband CSI on PUCCH formats 3 and 4, one-part CSI is used.

Agreement

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, regarding the value of the RRC-configured resource-level slot offset (relative to the resource-set-level slot offset) for aperiodic CSI-RS resource set, in addition to the agreed values of {0, 1, 2, 3}, the following values are supported: {4, 5, 6, 7}.

Agreement

For the Rel-19 Type-I SP codebook refinement for P=128 CSI-RS ports, with Capability 2 timeline, when periodic or semi-persistent CSI reporting is configured, n_{CSI_ref} is the smallest value greater than or equal to , such that it corresponds to a valid downlink slot.

R1-2501571 Moderator Summary#3 on Rel-19 CSI enhancements: Round 3 Moderator (Samsung)

From Thursday session

Agreement

Following agreement from RAN1#118bis is updated (in RED):

For the Rel-19 aperiodic standalone CJT calibration reporting, when ReportQuantity is ‘cjtc-P’ (DL/UL phase offset), regarding the configured associated SRS resource,

Confirm the following working assumption as agreement: “the configured associated SRS resource can be either periodic, semi-persistent, or aperiodic”

· When periodic or semi-persistent associated SRS resource is configured, the SRS transmission occasion for determining the reference UE antenna port corresponds to the latest SRS transmission occasion before the occasions of the N_TRP CSI-RS resources used for measuring ‘cjtc-P’ report

Note: when periodic or semi-persistent CSI-RS is configured, in case of time-domain Measurement Restriction not configured, the UE can assume that the occasions of the NTRP CSI-RS resources are the latest no later than the CSI reference resource.

9.2.3 Support for 3-antenna-port codebook-based transmissions

Including support for 3T3R and 3T6R SRS antenna switching.

R1-2500099 Discussion on 3-antenna-port UL transmission Huawei, HiSilicon

R1-2500106 3-antenna-port UL transmissions MediaTek Inc.

R1-2500117 Remaining Details on Rel-19 CB-based UL for 3TX UE InterDigital, Inc.

R1-2500219 Views on 3Tx uplink transmissions CATT

R1-2500243 Discussion on 3-antenna-port codebook-based transmissions ZTE Corporation, Sanechips

R1-2500281 Discussion on support for 3-antenna-port codebook-based transmissions CMCC

R1-2500344 Remaining issues on 3-antenna-port codebook-based uplink transmissions vivo

R1-2500472 Discussion on 3-antenna-port uplink transmissions OPPO

R1-2500539 Remaining issues for 3 Tx UL transmissions Ericsson

R1-2500551 Uplink 3 Port Codebook based Transmission Google

R1-2500701 Support for 3-antenna-port codebook-based transmissions Lenovo

R1-2500727 Discussion on the support of 3-antenna-port CB based transmissions Xiaomi

R1-2500773 Remaining issues on R19 MIMO 3Tx transmission Apple

R1-2500842 Views on Rel-19 3-antenna-port codebook-based transmissions Samsung

R1-2500879 Discussions on 3-antenna-port codebook-based UL transmission China Telecom Corporation Ltd.

R1-2500898 On the support for 3-antenna-port codebook-based transmissions Nokia

R1-2500932 Discussion on uplink enhancement for UE with 3Tx Fujitsu

R1-2501129 Support for 3-antenna-port transmission Sharp

R1-2501151 Remaining issues for 3Tx CB based PUSCH Qualcomm Incorporated

R1-2501197 Discussion on support for 3-antenna-port codebook-based transmissions NTT DOCOMO, INC.

R1-2500119 FL Summary Support for 3TX CB-based Uplink; First Round Moderator (InterDigital, Inc.)

From Monday session

Agreement

For 3T3R antenna switching, reuse the same mechanism as xTxR for the SRS configuration as follows:

· Up to two SRS resource sets each with one SRS resource can be configured, where the number of SRS ports for each resource is equal to 4 with port 1003 disabled if the UE is not indicating srs-AntennaSwitching2SP-1Periodic.

· Up to two SRS resource sets configured with resourceType in SRS-ResourceSet set to 'semi-persistent' and one SRS resource set configured with resourceType in SRS-ResourceSet set to 'periodic' can be configured and the two SRS resource sets configured with 'semi-persistent' are not activated at the same time, or up to two SRS resource sets can be configured, if the UE is indicating srs-AntennaSwitching2SP-1Periodic, where each SRS resource set has one SRS resource, the number of SRS ports for each resource is equal to 4 with port 1003 disabled.

· For 3T=3R, the UE shall not expect to be configured or triggered with more than one SRS resource set with higher layer parameter usage set as 'antennaSwitching' in the same symbol.

Note: This is not meant to be a text proposal to be captured for the specifications.

Conclusion

To support 3T3R antenna switching for a 3TX UE,

Reuse the power control parameters configuration principles, i.e., 3T6R, when two aperiodic SRS resource sets are configured,

If a UE is provided TCI-State in dl-OrJointTCI-StateList or TCI-UL-State, the UE shall expect that the two SRS resource sets are associated with the same values of the higher layer parameters p0AlphaSetforSRS and pathlossReferenceRS-Id
Otherwise, the UE shall expect that the two SRS resource sets are configured with the same values of the higher layer parameters alpha, p0, pathlossReferenceRS, and srs-PowerControlAdjustmentStates in SRS-ResourceSet.

Conclusion

For a 3TX UE, following agreements for codebook-based transmission can also be extended for non-codebook-based transmission,

Agreement

For codebook-based transmission by a 3TX UE,

- Option- 2: Subject to UE capability, up to 2 PTRS ports may be configured in PTRS-UplinkConfig,

o FFS whether a single bit or 2 bits are used for PTRS-DMRS association indication.

Above is only for single panel transmission.

Agreement

For codebook-based UL transmission by a 3TX UE, when 1 PTRS port is configured by maxNrofPorts in PTRS-UplinkConfig, PTRS-DMRS association indication is as follows:

- Alt2: 2-bit indication

PTRS-DMRS association when 1 PT-RS port is configured

Value	DMRS port
0	1^st scheduled DMRS port
1	2^nd scheduled DMRS port
2	3^rd scheduled DMRS port
3	~~4^th scheduled DMRS port~~ Reserved

Agreement

For non-codebook-based UL transmission for a 3TX UE, when 2 PTRS ports are configured by maxNrofPorts in PTRS-UplinkConfig, PTRS-DMRS association indication for the two DMRS ports that share a PTRS port is as follows:

Value of MSB	DMRS port	~~Value of LSB~~	~~DMRS port~~
0	1st DMRS port which shares the PTRS port	0	~~1st DMRS port which shares PTRS port 1~~
1	2nd DMRS port which shares the PTRS port	1	~~2nd DMRS port which shares PTRS port 1~~

Number of bits used for the indication

1 bit

Above is applicable for when a 3TX UE is configured with 3 SRS resources for non-codebook-based UL transmission

Conclusion

For a 3TX UE, following agreements for codebook-based transmission can also be extended for non-codebook-based transmission,

Agreement

For codebook-based M-TRP PUSCH repetition by a 3TX UE, for indication of PTRS-DMRS association,

- When 1 PTRS port is configured by maxNrofPorts in PTRS-UplinkConfig, reuse Rel-17 multi-TRP TDM repetition,

- When 2 PTRS ports are configured by maxNrofPorts in PTRS-UplinkConfig, and maxRank = 2 or 3,

o A second PTRS-DMRS association field (1 bit) is used to indicate the association between PTRS ports and DMRS ports for the 2nd SRS resource set (i.e.,2nd TRP).

Agreement

For 3T3R and 3T6R antenna switching, support the following separate UE capabilities for SRS configuration,

· “srs-AntennaSwitching3T6R2SP-1Periodic” to extend srs-AntennaSwitching2SP-1Periodic to the case of 3T6R.

· “srs-AntennaSwitching3T3R2SP-1Periodic” to extend srs-AntennaSwitching2SP-1Periodic to the case of 3T3R.

Final summary in:

R1-2500121 Summary of Discussion on 3TX CB-based Uplink in RAN1#120 Moderator (InterDigital, Inc.)

9.2.44 Enhancement for asymmetric DL sTRP/UL mTRP scenarios

Including support for 2TA without CoresetPoolIdx association for asymmetric DL sTRP/UL mTRP.

R1-2500100 Enhancements for asymmetric DL sTRP/UL mTRP scenarios Huawei, HiSilicon

R1-2500107 Enhancement for asymmetric DL sTRP/UL mTRP scenarios MediaTek Inc.

R1-2500118 Remaining Details on Rel-19 Asymmetric mTRP Operation InterDigital, Inc.

R1-2500165 Enhancements for asymmetric DL sTRP/UL mTRP scenarios Spreadtrum, UNISOC

R1-2500220 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios CATT

R1-2500239 Discussion on asymmetric DL sTRP/UL mTRP scenarios TCL

R1-2500244 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios ZTE Corporation, Sanechips, China Telecom

R1-2500256 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios China Telecom, ZTE

R1-2500282 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios CMCC

R1-2500345 Remaining issues on asymmetric DL sTRP/UL mTRP scenarios vivo

R1-2500473 Enhancements on asymmetric DL sTRP/UL mTRP scenarios OPPO

R1-2500495 Remaining issues on asymmetric DL sTRP UL mTRP scenarios Ericsson

R1-2500498 Enhancement for asymmetric DL sTRP UL mTRP Tejas Network Limited

R1-2500514 Enhancements on asymmetric DL STRP/UL MTRP scenarios Ofinno

R1-2500570 Discussions on asymmetric DL sTRP/UL mTRP scenarios LG Electronics

R1-2500593 Discussion on enhancements for asymmetric DL sTRP and UL mTRP scenarios NEC

R1-2500647 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Sony

R1-2500702 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Lenovo

R1-2500728 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios Xiaomi

R1-2500774 Enhancements for asymmetric DL sTRP/UL mTRP Apple

R1-2500843 Views on Rel-19 asymmetric DL sTRP/UL mTRP scenarios Samsung

R1-2500899 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Nokia

R1-2500907 Discussion on UL mTRP and DL single TRP operation ETRI

R1-2500933 Discussion on UL-only mTRP operation Fujitsu

R1-2500964 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios Transsion Holdings

R1-2500978 "Enhancement for Asymmetric DL sTRP/UL mTRP Scenarios " Panasonic

R1-2501121 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Sharp

R1-2501152 Enhancement for asymmetric DL sTRP and UL mTRP deployment scenarios Qualcomm Incorporated

R1-2501198 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios NTT DOCOMO, INC.

R1-2501237 Discussion on asymmetric DL sTRP and UL mTRP ASUSTeK

R1-2501335 Discussion on enhancement for asymmetric DL sTRP and UL mTRP scenarios Google

R1-2501358 Summary #1 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

From Monday session

Agreement

For a UE provided with SSB-MTC-AddtionalPCI and not configured with multi-DCI based mTRP, support to reuse the DCI field ‘PRACH association indicator’ in DCI format 1_0 to indicate PL RS for PDCCH-order PRACH:

The bit field index 0 of this field indicates the DL RS that DMRS of PDCCH order DCI is QCLed with is used as PL RS for PRACH;
The bit field index 1 of this field is mapped to the additional PCI associated with the active TCI states and indicates the indicated SSB in this DCI is used as PL RS for PRACH:

In this case, the PRACH configuration associated with addition PCI is used.

This DCI field is present when the corresponding RRC parameter is configured and multi-DCI based mTRP is not configured.

Conclusion

There is no RAN1 consensus to support the following proposal:

Support the UE to report either Type1 PHR or Type 3 PHR in a serving cell configured with one UL carrier and two separate SRS CLPC adjustment states. The UE determines to report Type1 PHR or Type 3 PHR according to:

UE provides the Type 1 PHR if both the Type 1 PHR and the Type 3 PHR are based on respective actual transmissions or on respective reference transmissions.
UE provides the PHR that is based on a respective actual transmission if either the Type 1 PHR or the Type 3 PHR is based on a respective reference transmission.

This is subject to UE capability.

This is feature is enabled by one new RRC parameter.

R1-2501359 Summary #2 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

From Tuesday session

Conclusion

There is no consensus to introduce the restriction that only one of the indicated joint/UL TCI states can be configured with PL offset.

Conclusion

There is no consensus to include PL offset in Type 3 PHR calculation.

Conclusion

In asymmetric DL sTRP/UL mTRP deployment scenario, the PDCCH-order PRACH to UL TRP is CFRA.

Agreement

The legacy TPC application mechanisms specified in legacy spec are reused for the TPC command for separate SRS CLPC adjustment state(s) indicated in DCI format 1_1 in Rel-19 and the TPC command for separate SRS CLPC adjustment states indicated in DCI format 2_3 in Rel-19.

One example specification changes in TS38.213 can be

7.3.1 UE behavior

*** Unchanged parts are omitted ***

- is jointly coded with other TPC commands in a PDCCH with DCI format 2_3, as described in clause 11.4 or provided by TPC command field XXX in a PDCCH with DCI format 1_1

*** Unchanged parts are omitted ***

- if the UE is not configured for PUSCH transmissions on active UL BWP of carrier of serving cell , or if srs-PowerControlAdjustmentStates indicates separate power control adjustment states between SRS transmissions and PUSCH transmissions, and tpc-Accumulation is provided, and the UE detects a DCI format 2_3 or DCI format 1_1 carrying DCI field XXX symbols before a first symbol of SRS transmission occasion , where absolute values of are provided in Table 7.1.1-1

*** Unchanged parts are omitted ***

o Note: how to capture this in specification is up to editor.

· In Rel-19, the TPC command for separate SRS CLPC adjustment state(s) indicated in DCI format 1_1 and the TPC command for separate SRS CLPC adjustment states indicated in DCI format 2_3 are applicable to periodic SRS, semi-persistent SRS and aperiodic SRS.

R1-2501360 Summary #3 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

From Thursday session

Agreement

Study whether/how to reset the CLPC of PUSCH/PUCCH/SRS based on the following alternatives (including if any enhancement is necessary and other alternatives are not precluded)

Alt1: For a UE configured with two TAGs, when the UE receives a RAR of a PDCCH-order PRACH, according to the new 1-bit DCI field PL offset indication in DCI format 1_0:

When there is one indicated joint/UL TCI state in Rel-17 Unified TCI:

If the 1-bit DCI field is 0, the UE resets the CLPC that is different from the CLPC associated with the indicated joint/UL TCI state.
If the 1-bit DCI field is 1, the UE resets the CLPC associated with the indicated joint/UL TCI state.

When there are two indicated joint/UL TCI states in Rel-18 Unified TCI:

If the 1-bit DCI field is 0, the UE resets the CLPC associated with the first indicated joint/UL TCI state;
If the 1-bit DCI field is 1, the UE resets the CLPC associated with the second indicated joint/UL TCI state

Alt 2: For a UE configured with two TAGs, one TAG ID is indicated in the RAR

The UE resets the closed loop power control adjustment state associated with a joint/UL TCI state associated with the indicated TAG.

RAN1#120-bis

9.2 NR MIMO Phase 5

Please refer to RP-242394 for detailed scope of the WI. Additional RAN guidance on Rel-19 NR MIMO can be found in RP-243265.

[120bis-R19-MIMO] – Gilwon (Samsung)

Email discussion on Rel-19 MIMO Phase 5

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2502361 List of RRC impact for Rel-19 MIMO Ph5 Moderator (Samsung)

R1-2502364 Draft Stage-2 CR for Rel-19 NR MIMO Ph5 in TS38.300 Samsung

R1-2503093 Summary of discussion on Draft CR on TS38.300 for Rel-19 MIMO Moderator (Samsung)

R1-2502362 Draft LS to RAN2 on MAC impact for Rel-19 MIMO Ph5 Moderator (Samsung)

Thursday decision: RAN1 consensus that such LS is not needed and not pursued.

9.2.1 Enhancements for UE-initiated/event-driven beam management

R1-2501716 Enhancements for UE-initiated/event-driven beam management FUTUREWEI

R1-2501742 On Specifications of Rel-19 UE/Event-Driven Beam Management InterDigital, Inc.

R1-2501780 Discussion on enhancements for UE-initiated/event-driven beam management ZTE Corporation, Sanechips

R1-2501799 Remaining issues on UE-initiated/event-driven beam management vivo

R1-2501850 Enhancements for UE-initiated/event-driven beam management MediaTek Inc.

R1-2501862 Discussion on UE-initiated/event-driven beam management Spreadtrum, UNISOC

R1-2501985 On enhancements for UE-initiated/event-driven beam management CATT

R1-2502038 On UE-initiated/event-driven beam management Ofinno

R1-2502053 Remaining issues for UE-initiated beam management Ericsson

R1-2502065 Discussions on UEIBM China Telecom

R1-2502079 Discussion on enhancements for UE-initiated or event-driven beam management NEC

R1-2502103 UE-initiated beam management LG Electronics

R1-2502107 Enhancements for UE-initiated/event-driven beam management Lenovo

R1-2502119 Discussion on enhancements for UE-initiated/event-driven beam management Fujitsu

R1-2502153 Discussion on enhancements for UE-initiated/event-driven beam management CMCC

R1-2502224 On UE initiated/event-driven beam management Huawei, HiSilicon

R1-2502293 Discussions on UE-initiated/event-driven beam management OPPO

R1-2502312 Enhancements for UE-initiated/event-driven beam management Sony

R1-2502356 Views on Rel-19 UE-initiated/event-driven beam management Samsung

R1-2502414 Discussion on enhancements for UE-initiated/event-driven beam management Ruijie Networks Co. Ltd

R1-2502434 Discussion on enhancements for UE-initiated/event-driven beam management Xiaomi

R1-2502505 Enhancements for UE-initiated/event-driven beam management ETRI

R1-2502524 Enhancements to facilitate UE-initiated/event-driven beam management Nokia

R1-2502538 Enhancements for UE-initiated/event-driven beam management Transsion Holdings

R1-2502545 Discussion on UE-initiated/event-driven beam management TCL

R1-2502598 Remaining issues for UE-initiated beam management Apple

R1-2502665 Enhancements for UE-initiated/event-driven beam management Sharp

R1-2502687 Discussion on the UE-initiated/event-driven beam management HONOR

R1-2502744 Offline summary for Rel-19 MIMO UEIBM (9.2.1) pre-RAN1#120b Moderator (ZTE)

R1-2502759 Discussion on enhancements for UE-initiated/event-driven beam management NTT DOCOMO, INC.

R1-2502793 Discussion on UE-initiated/event-driven beam management ITRI

R1-2502812 Enhancements for UE-initiated/event-driven beam management Panasonic

R1-2502833 UE-initiated/event-driven beam management Qualcomm Incorporated

R1-2502877 Discussion on UE initiated beam report ASUSTeK

R1-2502888 Discussion on enhancements for UE-initiated or event-driven beam management Google

R1-2502897 Discussions on enhancements for UE-initiated/event-driven beam management KDDI Corporation (TTC)

R1-2502745 Moderator Summary #1 on UE-initiated/event-driven beam management Moderator (ZTE)

From Monday session

Agreement

Regarding triggering event determination for Event 2, on resetting the counting, the following modification on the agreed Candidate #2 in RAN1#120 is supported.

· Candidate#2: [The measured current beam RS is updated based on] indicated TCI state ~~is updated~~;

o In such case, the UE needs to reset the counting for all new beams.

o FFS: Further details on the update (if necessary).

Agreement

On UE-initiated/event-driven beam reporting, support the following interpretation on each of the codepoints of the ‘1-bit’ condition met indicator as follows:

· ‘0’ – indicating that the Event-2 instances for corresponding CRI/SSBRI within the time window doesn’t reach the configured number M.

· ‘1’ – indicating that the Event-2 instances for corresponding CRI/SSBRI within the time window reach the configured number M.

FFS: whether/how to introduce the ‘1-bit’ condition met indicator for Event 7.

Agreement

On cross-CC beam report measurement for UE-initiated/event-driven beam reporting, regarding Event-2, introduce an RRC parameter to indicate ServCellIndex on which the indicated TCI state used to determine the current beam RS is applied.

· FFS: Indication of the cell that corresponds to the configured first PUCCH resource in CSI report config including whether it is necessary

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, for the case the pre-configured Type-1 CG PUSCH carry the beam report, for the second UL channel in Mode-B, reuse the intra-UE multiplexing/prioritization rules of PUSCH with SP-CSI for Type-1 CG PUSCH with UEI-BR for Mode B.

Agreement

Regarding triggering event determination for Event 2, on the measurement window for initiating the UE-initiated/event-driven beam reporting procedure, down-select one of the following options in RAN1#120bis.

Option-1: The measurement window is from T_PUCCH – T_proc – T_window to T_PUCCH – T_proc, where T_PUCCH is a transmission occasion of a first PUCCH, and T_proc is RRC configured.
Option-2: The measurement window is from T_Instance – T_window to T_Instance, where T_Instance is an evaluation occasion of event instance.

The UEI beam report in the second PUSCH is based on the most recent measurement for new/current beam RS(s).

Option-2A: The measurement window is from T_Instance – T_window to T_Instance, where T_Instance is the time when an event instance for the new beam is determined.

The UEI beam report in the second PUSCH is based on the most recent measurement for new/current beam RS(s).

Option-3: The length, slot offset and periodicity of a measurement window are configured per CSI report configuration by NW.
Option-4: If an Event-2 instance for a new beam is obtained at the time [and the time for the new beam is not running], UE (re)starts the timer for the new beam, where the expiry time of the timer is equal to the NW-configured length of the time window (T_window)
Note: T_window is the agreed time window parameter for measurement.

R1-2502746 Moderator Summary #2 on UE-initiated/event-driven beam management Moderator (ZTE)

From Tuesday session

Agreement

On UE-initiated/event-driven beam reporting, support the following for Event 1:

Regarding report format of L1-RSRP value of current beam,

Option-A2: L1-RSRP of current beam is absolute L1-RSRP (7-bit quantized, rather than 4-bit as in Event-2).

Agreement

On UE-initiated/event-driven beam reporting, regarding current beam report on Event 1, reuse RRC parameter enabledCurrentBeamReport-r19 to enable/disable the RSRP report of current beam.

Conclusion

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the case that one PUCCH resource of first PUCCH can be associated with one or multiple CSI report configurations, there is NO RAN1 consensus on supporting multiple UEI beam reports carrying in a second PUSCH.

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH, support the following rule for the Case-4: the 1-bit first PUCCH is collided/overlapped with a PUCCH format 0/1 carrying HARQ.

Option-1: Follow legacy SR multiplexing rule.

Note: There is no further enhancement on additional phase offset/constellation point(s).

Conclusion

Regarding resource mapping/configuration between first and second UL channel associated with a same CSI report configuration in Mode-B, there is NO consensus on further supporting the case that first PUCCH resource and pre-configured resource for second UL channel can have different periodicities (in ms).

R1-2502747 Moderator Summary #3 on UE-initiated/event-driven beam management Moderator (ZTE)

From Wednesday session

Agreement

Regarding triggering event determination for Event 2, on the measurement window for initiating the UE-initiated/event-driven beam reporting procedure, support Option-4.

Option-4: If an Event-2 instance for a new beam is obtained at the time and the timer for the new beam is not running, UE starts the timer for the new beam, where the expiry time of the timer is equal to the NW-configured length of the time window (T_window)

Note: Timer is new beam specific.

Note: T_window is the agreed time window parameter for measurement.
Introduce separate UE capability to limit the number of timers. There is only 1 timer per new beam.

Above agreement is captured in RAN1 specifications.

Agreement

On UE-initiated/event-driven beam reporting, the procedure of triggering event determination is captured in RAN1 spec.

R1-2503092 Moderator Summary #4 on UE-initiated/event-driven beam management Moderator (ZTE)

From Thursday session

Conclusion

There is no RAN1 consensus on the following proposal:

On UE-initiated/event-driven beam reporting, support at least Option-1 of following for Event 7 as an extension on report format for Event-2

Option-1: Additional field to indicate the codepoint of the activated TCI state with Q-th best quality.

FFS: Further report codepoints of other activated TCI state(s) [, e.g., from {Q+1}-th best quality to the worst one];
FFS: Details of the additional indication.

Option-2: Extending the maximum number of reported RS(s) to 8.

[Note: If Option 2 is agreed, RAN1 can revisit the agreed maximum value of N for event-2.]

Above is applicable only if time window and a configurable value M for event counting on Event-7 are not configured.

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting for a CSI report configuration, down-select at least one of the following candidates in RAN1#121:

Candidate#1: To introduce a prohibit timer for mode-A and/or mode-B

Option-1A: In the case that triggering-event associated with the CSI report configuration is determined [by the same triggering beams(s) as the last transmitted PUCCH], if the prohibit timer is NOT running, the UE can transmit first PUCCH;

At the first symbol after the end of the PUSCH transmission, the UE starts the prohibit timer

Option-1B: In the case that triggering-event associated with the CSI report configuration is determined, if the prohibit timer is NOT running, the UE can transmit first PUCCH;

At the first symbol after the end of the first PUCCH transmission, the UE starts the prohibit timer

If the prohibit timer is running, the first PUCCH is not allowed to be transmitted.

Candidate#2: To introduce a time interval for mode-A and/or mode-B

Option-2A: For a first PUCCH transmission occasion, if there is a transmission of another second PUSCH [corresponding to the CSI report determined by the same triggering beam(s) as the first PUCCH] within a configurable time interval before the first PUCCH transmission occasion, the UE should not transmit the first PUCCH.
Option-2B: For a first PUCCH transmission occasion, if there is a transmission of another first PUCCH(s) within a configurable time interval before the first PUCCH transmission occasion, the UE should not transmit the first PUCCH.

Candidate#3: No further enhancement.

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH, down-select one of the following rules for the Case-2: the 1-bit first PUCCH is collided/overlapped with a PUSCH, in RAN1#121

Option-1: Prioritize first PUCCH over PUSCH, i.e., PUSCH is dropped.

FFS: If the PUSCH should be with UL-SCH or not for UEI beam report

Option-3: Piggyback 1-bit indication of first PUCCH into the PUSCH.

FFS: The 1-bit indication is always multiplexed in the PUSCH, regardless that UEI beam report procedure is triggered.
FFS: If the PUSCH should be with UL-SCH or not for UEI beam report

Option-4: Reuse the SR dropping rules.
FFS: whether/how to handle the case of different PHY priorities.

Conclusion

There is no RAN1 consensus on the following. No spec change needed.

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH, support one of the following rule for the Case-3: the 1-bit first PUCCHs corresponding to different CSI configuration for UE-initiated/event-driven beam reporting are overlapping in the time domain.

Option-1: Per CSI report configuration.
Option-2: Up to implementation.
Option-3: UE transmits the first PUCCH with higher priority (e.g., PUCCH resource with lower PUCCH resource ID, or event-type).
Option-4: Multiplexing all 1-bit indications.

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, confirming the following working assumption with the following modification.

· For Mode-A, the multiple CSI report configurations associated with the same PUCCH resource should be associated with a same CSI-AperiodicTriggerState.

· FFS: For Mode-A, the multiple CSI report configurations associated with the same CSI-AperiodicTriggerState should be associated with a same PUCCH resource.

Conclusion

There is no RAN1 consensus on the following. No spec change needed.

For event 2, when one PUCCH resource of first PUCCH can be associated with one or multiple CSI report configurations, and if multiple UE initiated beam report procedures occur, down-select one of the following options:

Option-1: It is up to UE implementation to select one of configuration.
Option-2: The UEI beam report with highest priority is reported.

FFS: priority, e.g., lowest CSI-ReportConfigId, event-type or based on legacy CSI report priority rule.

Option-3: The report triggered in the latest measurement is reported in PUSCH.

9.2.2 CSI enhancements

Including support for up to 128 CSI-RS ports on FR1 and UE reporting enhancement for CJT and SRS port grouping for TDD low-complexity 6/8RX receiver.

R1-2501743 On Specifications of Rel-19 Enhancements of CSI InterDigital, Inc.

R1-2501781 Discussion on CSI enhancements ZTE Corporation, Sanechips

R1-2501800 Remaining issues on Rel-19 CSI enhancements vivo

R1-2501851 CSI enhancements MediaTek Inc.

R1-2501863 Discussion on CSI enhancements Spreadtrum, UNISOC

R1-2501950 CSI Enhancement for NR MIMO Google

R1-2501986 Remaining issues on CSI enhancements for NR MIMO Phase 5 CATT

R1-2502011 Discussion on Rel-19 CSI Enhancements Tejas Network Limited

R1-2502074 Discussion on CSI enhancements NEC

R1-2502108 Discussion on CSI enhancements Lenovo

R1-2502120 Remaining issues on Rel-19 CSI enhancements Fujitsu

R1-2502154 Discussion on CSI enhancements CMCC

R1-2502225 On 128 CSI-RS ports and UE reporting enhancement Huawei, HiSilicon

R1-2502294 CSI enhancements for Rel-19 MIMO OPPO

R1-2502313 Further discussion of CSI enhancements Sony

R1-2502358 Views on Rel-19 CSI enhancements Samsung

R1-2502435 Maintenance on CSI enhancement for up to 128 ports and CJT Xiaomi

R1-2502506 Discussion on CSI enhancements for NR MIMO Phase 5 ETRI

R1-2502525 CSI enhancement for NR MIMO Phase 5 Nokia

R1-2502551 Discussion on the Remaining Issues of CSI Enhancement Rakuten Mobile, Inc

R1-2502599 Views on R19 MIMO CSI enhancement Apple

R1-2502666 CSI enhancements Sharp

R1-2502688 Discussion on CSI enhancements HONOR

R1-2502730 Discussion on Beamforming Template for CSI Enhancement China Unicom

R1-2502760 Discussion on CSI enhancements NTT DOCOMO, INC., NTT CORPORATION

R1-2502811 Maintenance on CSI for large antenna arrays and CJT Ericsson

R1-2502834 CSI enhancements for >32 ports and UE-assisted CJT Qualcomm Incorporated

R1-2502904 CSI enhancements for Rel. 19 MIMO Fraunhofer IIS, Fraunhofer HHI

R1-2502932 Discussion on CSI enhancements for NR MIMO Phase 5 KDDI Corporation

R1-2502357 Moderator Summary#1 on Rel-19 CSI enhancements: Round 1 Moderator (Samsung)

From Monday session

Agreement

For the Rel-19 Type-I multi-panel (MP) codebook refinement for a given P{48, 64, 128} CSI-RS ports, the mapping of i_1,3 to (k₁,k₂) for RI=2-4 is the same as that used in the Rel-19 Type-I SP Scheme-A for RI=2-4 and .

· Note: How this is captured is up to the TS38.214 editor.

Agreement

For the Rel-19 Type-I multi-panel (MP) codebook refinement for 48, 64, and 128 CSI-RS ports, support only the following (N_g, N₁, N₂) values (revision from the current version of editor draft CR on TS 38.214):

Number of CSI-RS antenna ports,
48	(2,4,3)
	(2,6,2)
	~~(2,12,1)~~
64	(2,4,4)
	(2,8,2)
	~~(2,16,1)~~
	(4,4,2)
	~~(4,8,1)~~
128	(4,4,4)
	(4,8,2)
	~~(4,16,1)~~

Conclusion

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports, when the Rel-18 SD NES Type-I is configured for the Rel-19 Type-I SP codebook, the powerOffset parameter can be configured in all the respective subConfiguration IEs

· The supported values for powerOffset follow the legacy specification.

Conclusion

There is no RAN1 consensus on the following proposal:

For the Rel-19 aperiodic standalone CJT calibration reporting, regarding the dynamic range for delay offset reporting D_n,offset, i.e. A_D, also support

A_D = {0.1CP, 0.2CP}.

· Each of the above values of the dynamic ranges is subject to a separate UE capability.

· Each of the above values of the dynamic ranges is applicable when the bandwidth of configured TRS is no smaller than 52 PRBs

R1-2503013 Moderator Summary for 1^st offline on Rel-19 CSI enhancements Moderator (Samsung)

R1-2503011 Moderator Summary#2 on Rel-19 CSI enhancements: Round 2 Moderator (Samsung)

From Wednesday session

Conclusion

For the Rel-19 Type-I multi-panel (MP) codebook refinement for 48, 64, and 128 CSI-RS ports, there is no need to support any mapping from CSI-RS resource index and CSI-RS resource port index per resource to port index for CSI/PMI calculation.

Conclusion

There is no consensus to support the following proposal:

For the Rel-19 CRI-based CSI refinement for up to 128 CSI-RS ports, regarding aperiodic CSI-RS resource configuration, support configuring, via higher-layer (RRC) signalling, an available slot offset for each CSI-RS resource within the aperiodic CSI-RS resource set.

Agreement

For the Rel-19 Type-I and Type-II (except for Type-II Doppler) codebook refinement for 48, 64, and 128 CSI-RS ports, when the K>1 aggregated NZP aperiodic CSI-RS resources for CMR are within two consecutive slots, the triggering offset of the associated aperiodic CSI-IM follows the associated NZP CSI-RS resource(s) for CMR in the first slot.

FFS: How to resolve this for Rel-19 Type-II Doppler

9.2.3 Support for 3-antenna-port codebook-based transmissions

Including support for 3T3R and 3T6R SRS antenna switching.

R1-2501744 On Specifications of Rel-19 CB-based UL for 3TX UE InterDigital, Inc.

R1-2501782 Discussion on 3-antenna-port codebook-based transmissions ZTE Corporation, Sanechips

R1-2501801 Remaining issues on 3-antenna-port codebook-based uplink transmissions vivo

R1-2501852 3-antenna-port UL transmissions MediaTek Inc.

R1-2501941 Remaining issues for 3 Tx UL transmissions Ericsson Japan K.K.

R1-2501951 Uplink 3 Port Codebook based Transmission Google

R1-2501987 Remaining issues on 3-antenna-port uplink transmission CATT

R1-2502109 Support for 3-antenna-port codebook-based transmissions Lenovo

R1-2502155 Discussion on support for 3-antenna-port codebook-based transmissions CMCC

R1-2502226 Discussion on 3-antenna-port UL transmission Huawei, HiSilicon

R1-2502295 Discussion on 3-antenna-port uplink transmissions OPPO

R1-2502359 Views on Rel-19 3-antenna-port codebook-based transmissions Samsung

R1-2502436 Discussion on the support of 3-antenna-port CB based transmissions Xiaomi

R1-2502526 On the support for 3-antenna-port codebook-based transmissions Nokia

R1-2502600 Remaining issues on R19 MIMO 3Tx transmission Apple

R1-2502667 Support for 3-antenna-port transmission Sharp

R1-2502761 Discussion on support for 3-antenna-port codebook-based transmissions NTT DOCOMO, INC.

R1-2501746 FL Summary Support for 3TX CB-based Uplink; First Round Moderator (InterDigital, Inc.)

From Monday session

Agreement

Adopt the following changes in Clause 6.3.1.5 in TS38.211.

6.3.1.5 Precoding

The block of vectors shall be precoded according to

where , . The set of antenna ports shall be determined according to the procedure in [6, TS 38.214].

For non-codebook-based transmission, the precoding matrix equals the identity matrix.

For codebook-based transmission, the precoding matrix depends on the number of antenna ports used for the transmission:

- for single-layer transmission on a single antenna port, ;

- for transmissions using 2, or 4 antenna ports, is given by Tables 6.3.1.5-1 to 6.3.1.5-7;

- for transmissions using 3 antenna ports when 4portSRS_3TX is configured, ~~the UE does not transmit on antenna port 1003 and~~ is given by Tables 6.53.1.5-48 to 6.3.1.5-50;

Agreement

Adopt the following changes in Clause 6.2.1.2 in TS38.214.

6.2.1.2 UE sounding procedure for DL CSI acquisition

-------------------------------------------Unchanged parts are omitted-------------------------------------------

· - For 1T=1R, 2T=2R, 3T=3R, 4T=4R or 8T=8R, up to two SRS resource sets each with one SRS resource can be configured, where the number of SRS ports for each resource is equal to 1, 2, 4 with port 1003 disabled by higher layer parameter [RRC_parameter] is configured, 4 or 8 if the UE is not indicating srs-AntennaSwitching2SP-1Periodic or [srs-AntennaSwitching3T3R2SP-1Periodic]. Up to two SRS resource sets configured with resourceType in SRS-ResourceSet set to 'semi-persistent' and one SRS resource set configured with resourceType in SRS-ResourceSet set to 'periodic' can be configured and the two SRS resource sets configured with 'semi-persistent' are not activated at the same time, or up to two SRS resource sets can be configured, if the UE is indicating srs-AntennaSwitching2SP-1Periodic, srs-AntennaSwitching8T8R2SP-1Periodic, or [srs-AntennaSwitching3T3R2SP-1Periodic], where each SRS resource set has one SRS resource, the number of SRS ports for each resource is equal to 1, 2, 4 with port 1003 disabled by higher layer parameter [RRC_parameter] is configured, 4, or 8 or

-------------------------------------------Unchanged parts are omitted-------------------------------------------

· - For 3T6R, zero or one or two SRS resource sets configured with a different value of resourceType in SRS-ResourceSet set to 'periodic' or 'semi-persistent' and with higher layer parameter [RRC_parameter] is configured if the UE is not indicating ~~[srs-AntennaSwitching2SP-1Periodic] or~~ [srs-AntennaSwitching3T6R2SP-1Periodic], or up to two SRS resource sets configured with 'semi-persistent' and up to one SRS resource set configured with 'periodic' if the UE is indicating ~~[srs-AntennaSwitching2SP-1Periodic] or~~ [srs-AntennaSwitching3T6R2SP-1Periodic], where the two SRS resource sets configured with 'semi-persistent' are not activated at the same time. Each SRS resource set has two SRS resources transmitted in different symbols, each SRS resource in a given set consisting of a four SRS ports with port 1003 disabled, and the SRS ports of the resource in the set are associated with a different UE antenna ports, or

· - For 3T6R, zero or one or two SRS resource sets configured with resourceType in SRS-ResourceSet set to 'aperiodic' and with higher layer parameter [RRC_parameter] is configured, where in the case of one resource set has two SRS resources transmitted in different symbols, each SRS resource in a given set consisting of a four SRS ports with port 1003 disabled, and the SRS ports of the resource in the set are associated with a different UE antenna ports. In the case of two resource sets a total of two SRS resources are transmitted in different symbols of two different slots, and where the SRS ports of each SRS resource in the given two sets are associated with a different UE antenna ports.

-------------------------------------------Unchanged parts are omitted-------------------------------------------

From Tuesday session

Agreement

For a 3TX UE, when configured to ‘nonCodebook’, to distinguish UE behavior for PTRS-DMRS association between the Rel-19 and Rel-18 behavior,

Do not introduce a new RRC parameter, but enhance the definition of the RRC parameter 4portSRS_3Tx, for example,

‘1-bit RRC parameter to indicate that port 1003 is disabled for all the 4-port resources in an SRS resource set with usage ‘codebook’ or ‘antennaSwitching’, or to indicate 3-port transmission is enabled for a configured SRS resource set with usage ‘nonCodebook’.

From Wednesday session

Agreement

Adopt the following changes in Clause 6.2.1 in TS38.214.

6.2.1 UE sounding procedure

-------------------------------------------Unchanged parts are omitted-------------------------------------------

[The UE does not transmit SRS on antenna port 1003 if [RRC_parameter] is configured.] where [RRC_parameter] is only applicable when SRS resource(s) are configured with 4 ports with usage as codebook or antenna switching.

-------------------------------------------Unchanged parts are omitted-------------------------------------------

From Thursday session

Agreement

Adopt the following changes in Clause 7.1 - TS38.213 (Rel-19 endorsed draftCR in R1-2501661).

7.1 Physical uplink shared channel

For a PUSCH transmission on active UL BWP , as described in clause 12, of carrier of serving cell , a UE first calculates a linear value of the transmit power , with parameters as defined in clause 7.1.1. For a PUSCH transmission scheduled by a DCI format other than DCI format 0_0, or configured by ConfiguredGrantConfig or semiPersistentOnPUSCH, if txConfig in PUSCH-Config is set to 'codebook',

· - if ul-FullPowerTransmission in PUSCH-Config is provided, the UE scales by where:

-------------------------------------------Unchanged parts are omitted-------------------------------------------

· - else, if each SRS resource in the SRS-ResourceSet with usage set to 'codebook' has more than one SRS port, the UE scales the linear value by the ratio of the number of antenna ports with a non-zero PUSCH transmission power to the maximum number of SRS ports supported by the UE in one SRS resource ~~[if~~ ~~4portSRS_3Tx~~ ~~is not provided, or to 3 if 4portSRS_3Tx is provided~~].

-------------------------------------------Unchanged parts are omitted-------------------------------------------

R1-2501748 Summary of Discussion on 3TX CB-based Uplink in RAN1#120bis Moderator (InterDigital, Inc.)

9.2.44 Enhancement for asymmetric DL sTRP/UL mTRP scenarios

Including support for 2TA without CoresetPoolIdx association for asymmetric DL sTRP/UL mTRP.

R1-2501745 On Specifications of Rel-19 Asymmetric mTRP Operation InterDigital, Inc.

R1-2501783 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios ZTE Corporation, Sanechips, China Telecom

R1-2501802 Remaining issues on asymmetric DL sTRP/UL mTRP scenarios vivo

R1-2501853 Enhancement for asymmetric DL sTRP/UL mTRP scenarios MediaTek Inc.

R1-2501864 Enhancements for asymmetric DL sTRP/UL mTRP scenarios Spreadtrum, UNISOC

R1-2501988 Discussion on enhancements for asymmetric DL sTRP and UL mTRP scenarios CATT

R1-2502012 Enhancement for asymmetric DL sTRP UL mTRP Tejas Network Limited

R1-2502019 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios China Telecom, ZTE

R1-2502039 Enhancements on asymmetric DL STRP/UL MTRP scenarios Ofinno

R1-2502080 Discussion on enhancements for asymmetric DL sTRP and UL mTRP scenarios NEC

R1-2502104 Discussions on asymmetric DL sTRP/UL mTRP scenarios LG Electronics

R1-2502106 Remaining issues on asymmetric DL sTRP UL mTRP scenarios Ericsson

R1-2502110 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Lenovo

R1-2502156 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios CMCC

R1-2502227 Enhancements for asymmetric DL sTRP/UL mTRP scenarios Huawei, HiSilicon

R1-2502296 Enhancements on asymmetric DL sTRP/UL mTRP scenarios OPPO

R1-2502314 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Sony

R1-2502360 Views on Rel-19 asymmetric DL sTRP/UL mTRP scenarios Samsung

R1-2502437 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios Xiaomi

R1-2502507 Discussion on asymmetric UL MIMO operation ETRI

R1-2502527 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Nokia

R1-2502536 Discussion on asymmetric DL sTRP/UL mTRP scenarios TCL

R1-2502539 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios Transsion Holdings

R1-2502601 Enhancements for asymmetric DL sTRP/UL mTRP scenarios Apple

R1-2502670 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Sharp

R1-2502762 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios NTT DOCOMO, INC.

R1-2502813 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Panasonic

R1-2502835 Enhancement for asymmetric DL sTRP and UL mTRP deployment scenarios Qualcomm Incorporated

R1-2502889 Discussion on enhancement for asymmetric DL sTRP and UL mTRP scenarios Google

R1-2502953 Summary #1 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

From Monday session

Agreement

Answer the question of RAN4 as follows:

The RAN1 agreements in RAN1#118bis “One downlink reference timing is supported and applied to both TAGs” are NOT applied for the scenario that UE is not configured with PL offset in joint/UL TCI state(s) and UE may expect to receive SSB from UL TRP(s).

Agreement

For the scenario that the UE is configured with PL offset in joint/UL TCI state(s), when the UE is configured with rel-19 2 TAs, the UE maintains one single downlink reference timing
For the scenario that the UE is not configured with PL offset in joint/UL TCI state(s) and UE may expect to receive SSB from UL TRP(s), when the UE is configured with rel-19 2 TAs:

The UE maintains two downlink reference timings;
Baseline assumption for this feature is that Rx timing difference between two DL reference timings is no larger than one CP length, while it is subject to optional UE capability that the Rx timing difference between two DL reference timings can be assumed to be larger than CP length.
The reference point for PRACH transmission is indicated as follows:

if “PRACH association indicator” in DCI format 1_0 is 0, the reference timing is the first detected path (in time) of one of the corresponding downlink reference signal(s) of DL TCI state(s) of the reference cell associated with the first TAG.
if “PRACH association indicator” in DCI format 1_0 is 1, the reference timing is the first detected path (in time) of one of the corresponding downlink reference signal(s) of DL TCI state(s) of the reference cell associated with the second TAG.

Above applies for the case UE is configured with SSB-MTC-additionalPCI.

Agreement

For an SRS resource set not configured with followUnifiedTCI-StateSRS, regarding how to determine the PL offset and the CLPC adjustment state

Alt1: The PL offset and CLPC adjustment state indicated by the TCI state configured to the SRS resource with lowest ID (i.e., reusing the rule specified in Rel-17) and no additional enhancement.

When the UE is configured with Rel-19 2 TA, the above design is also applied to TAG.

From Wednesday session

R1-2502956 Draft Reply to RAN4 LS on DL timing reference to support two TA enhancement for asymmetric DL sTRP/ UL mTRP Moderator (OPPO)

Agreement

Reply to RAN4 LS on DL timing reference to support two TA enhancement for asymmetric DL sTRP/ UL mTRP is approved in R1-2503091.

R1-2502954 Summary #2 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

From Thursday session

Conclusion

There is no RAN1 consensus on the following proposal:

If the PL offset associated with the indicated joint/UL TCI state is included in the PRACH transmission power for PDCCH-order PRACH transmission, the pathlossReferenceRS-Id in the same indicated joint/UL TCI state is used to determine PL RS for the PDCCH-order PRACH transmission.

Companies are encouraged to consider the following for RAN1#121:

Regarding whether/how to reset the CLPC of PUSCH/PUCCH/SRS, further study and down-select one from the following alternatives:

Updated Alt1: For a UE configured with 2 TAGs, when the UE receives a RAR of a PDCCH-order PRACH:

If PL offset is configured in joint/UL TCI state(s), according to the new 1-bit DCI field PL offset indication in DCI format 1_0:

When there is one indicated joint/UL TCI state in Rel-17 Unified TCI:

If the 1-bit DCI field is 0, the UE resets the CLPC that is different from the CLPC associated with the indicated joint/UL TCI state.
If the 1-bit DCI field is 1, the UE resets the CLPC associated with the indicated joint/UL TCI state.

When there are two indicated joint/UL TCI states in Rel-18 Unified TCI:

If the 1-bit DCI field is 0, the UE resets the CLPC associated with the first indicated joint/UL TCI state;
If the 1-bit DCI field is 1, the UE resets the CLPC associated with the second indicated joint/UL TCI state

If PL offset is not configured in joint/UL TCI state(s) and the UE is configured with SSB-MTC-AddtionalPCI, according to the PRACH association indicator in DCI format 1_0:

If the indicated joint/UL TCI state is associated with the same PCI as indicated by the PRACH association indicator, the UE resets the closed loop power control adjustment state associated with the indicated joint/UL TCI state.
If the indicated joint/UL TCI state is associated with a different PCI from the one indicated by the PRACH association indicator, the UE resets the closed loop power control adjustment state that is different from the closed loop power control adjustment state associated with the indicated joint/UL TCI state.

Alt2: For a UE configured with two TAGs, one TAG ID is indicated in the RAR

The UE resets the closed loop power control adjustment state associated with a joint/UL TCI state associated with the indicated TAG.

Alt3: Not introduce any enhancement.

RAN1#121

9.2 NR MIMO Phase 5

Please refer to RP-242394 for detailed scope of the WI. Additional RAN guidance on Rel-19 NR MIMO can be found in RP-243265.

[121-R19-MIMO] Email discussion on Rel-19 MIMO Phase 5 – Eko (Samsung)

- To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2503559 List of RRC impact for Rel-19 MIMO Ph5 Moderator (Samsung)

R1-2503560 Draft LS to RAN2 on MAC impact for Rel-19 MIMO Ph5 Moderator (Samsung)

R1-2503561 LS to RAN2 on MAC impact for Rel-19 MIMO Ph5 Moderator (Samsung)

R1-2503562 Draft Stage-2 CR for Rel-19 NR MIMO Ph5 in TS38.300 Samsung

R1-2503721 AnImproved DOAEstimation Method Based on Sparse Reconstruction BUPT

Late submission

R1-2503722 An Improved DOA Estimation Method Based on Sparse Reconstruction BUPT

R1-2504568 Discussions on DOA estimation algorithm for MIMO BUPT

9.2.1 Enhancements for UE-initiated/event-driven beam management

R1-2503237 Remaining issues for UE-initiated/event-driven beam management FUTUREWEI

R1-2503275 On UE initiated/event-driven beam management Huawei, HiSilicon

R1-2503303 Enhancements for UE-initiated/event-driven beam management MediaTek Inc.

R1-2503351 Remaining issues on UE-initiated/event-driven beam management vivo

R1-2503433 Remaining Details of Rel-19 UE/Event-Driven Beam Management InterDigital, Inc.

R1-2503509 Discussion on UE-initiated/event-driven beam management Spreadtrum, UNISOC

R1-2503554 Views on Rel-19 UE-initiated/event-driven beam management Samsung

R1-2503612 Remaining issues for UE-initiated beam management Ericsson

R1-2503668 Discussion on enhancements for UE-initiated/event-driven beam management ZTE Corporation, Sanechips

R1-2503729 On UE-initiated/event-driven beam management Ofinno

R1-2503786 Remaining issues on UE-initiated/event-driven beam report CATT

R1-2503816 Enhancements for UE-initiated/Event-Driven Beam Management Panasonic

R1-2503824 Discussion on enhancements for UE-initiated/event-driven beam management CMCC

R1-2503876 Discussion on enhancements for UE-initiated/event-driven beam management Xiaomi

R1-2503912 Enhancements for UE-initiated/event-driven beam management Lenovo

R1-2503928 Discussion on enhancements for UE-initiated or event-driven beam management NEC

R1-2503953 Discussion on enhancements for UE-initiated/event-driven beam management Ruijie Networks Co. Ltd

R1-2503985 UE-initiated beam management LG Electronics

R1-2504061 Enhancements for UE-initiated/event-driven beam management Sony

R1-2504076 Enhancements to facilitate UE-initiated/event-driven beam management Nokia

R1-2504084 Discussion on enhancements for UE-initiated/event-driven beam management Fujitsu

R1-2504095 Discussion on the UE-initiated/event-driven beam management HONOR

R1-2504117 Discussion on enhancements for UE-initiated/event-driven beam management Hyundai Motor Company

R1-2504133 Enhancements for UE-initiated/event-driven beam management ETRI

R1-2504172 Enhancements for UE-initiated/event-driven beam management Transsion Holdings

R1-2504228 Discussions on UE-initiated/event-driven beam management OPPO

R1-2504297 Discussion on enhancements for UE-initiated or event-driven beam management Google

R1-2504312 Remaining issues for UE-initiated beam management Apple

R1-2504388 UE-initated/event-driven beam management Qualcomm Incorporated

R1-2504444 Enhancements for UE-initiated/event-driven beam management Sharp

R1-2504453 Discussions on UE-initiated/event-driven beam management China Telecom

R1-2504476 Remaining issues on enhancements for UE-initiated/event-driven beam management KDDI Corporation (TTC)

R1-2504495 Discussion on enhancements for UE-initiated/event-driven beam management NTT DOCOMO, INC.

R1-2504535 Discussion on UE-initiated/event-driven beam management ITRI, Acer Incorporated

R1-2504572 Discussion on UE initiated beam report ASUSTeK

R1-2504579 Discussion on Enhancements for UE-initiated/event-driven beam management NICT

R1-2504607 Discussion on UE-initiated/event-driven beam management TCL

R1-2504471 Moderator Summary #1 on UE-initiated/event-driven beam management Moderator (ZTE)

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the multiplexing a number of L (L>=1) PUCCH format 0/1 with UEIRIs are collided/overlapped with a PUCCH format 2/3/4 carrying HARQ/CSI, reuse the legacy SR multiplexing rule.

· The value of bits is based on an ascending order of the values of PUCCH resource ID associated with the first PUCCHs.

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the multiplexing a number of L (L>=1) first PUCCH is collided/overlapped with a PUCCH format 2/3/4 carrying HARQ/CSI/SR.

· Option-1: Extend the SR field of bits to a field of bits of representing at most one of positive SR or positive UEIRI

o The value in the field is based the ascending order of SR ID first and then the ascending order of the PUCCH resource ID associated with the first PUCCHs.

o If one of the SRs is a positive LRR, the value of the bits indicates the positive LRR, else, if one of the UEIBRs is a positive UEIBR, the value of the bits indicates the positive UEIBR.

o An all-zero value for the bits represents a negative SR and UEIRI value across all LRR/SRs and/or L UEIRIs.

R1-2504472 Moderator Summary #2 on UE-initiated/event-driven beam management Moderator (ZTE)

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding occupied CPU(s), O_CPU= 1 is occupied for a CSI report configuration.

- Note: That is the same number of occupied CPU for legacy L1-RSRP measurement.

Agreement

Regarding triggering event determination, on candidate values of supported RRC parameters,

- Support the following as RRC candidate values for a threshold value eventThreshold-r19 for trigger event detection regarding Event-2 or Event-7.

o Option-2: 0, 1, …, 30, 31 dB

- Support the following as RRC candidate values for a threshold value eventThreshold-Event1-r19 for trigger event detection regarding Event-1.

o Reusing RSRP-Range in RRC

§ Note: only values 14, …,113 in RSRP-Range are valid

- Support the following as RRC candidate values for the time window length for triggering event determination eventDetectionTimeWindowLength-r19

o 4, 5, 8, 10, 16, 20, 40, 80, 160, 320, 640, 1280 ms

- Support the following as RRC candidate values for the counting threshold eventInstanceCount-r19

o Option-1: 2, …, 16

Agreement

On cross-CC beam report measurement for UE-initiated/event-driven beam reporting, regarding Event-2, introduce an RRC parameter to indicate one from {SpCell, PUCCH-Scell} as the cell of the configured PUCCH.

- Note: It is up to NW implementation to configure same or different PUCCH resource IDs in different serving cells

R1-2504473 Moderator Summary #3 on UE-initiated/event-driven beam management Moderator (ZTE)

Agreement

On cross-CC beam report measurement for UE-initiated/event-driven beam reporting, regarding the evaluation periodicity for determining event instance, the periodicity of the current beam RS should be the same as that of the new beam RS(s).

- The evaluation periodicity is the same as the periodicity of the current and new beam RS(s).

Above applies for all events.

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the value of X symbols for determining available transmission occasion of the second UL channel on Mode-B

- Support Option-1 of the following as RRC candidate values for X symbols

· Option-1: 0, 1, 2, 4, 8, 16, 32, 64, 128, 256, 512

· Note: X is based on the SCS of the first PUCCH.

· Minimum value of X is subject to UE capability

- Regarding ‘available’ transmission occasion of the second UL channel, the transmission restriction for of the second UL channel reuses the legacy rule of PUSCH with SP-CSI.

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding the multiplexing/dropping rule(s) of 1-bit first PUCCH, support Option-3 of the following rules for the Case-2: the 1-bit first PUCCH is collided/overlapped with a PUSCH

- Option-3: Piggyback 1-bit indication of first PUCCH into the PUSCH.

o The 1-bit indication is always multiplexed in the PUSCH, regardless that UEI beam report procedure is triggered.

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding CSI reference resource definition for a UEI beam report, the CSI reference resource for a CSI reporting is defined by a single downlink slot , where slot n is determined according to the uplink slot n’ in which the second PUSCH is transmitted, and

- For mode-A, the legacy CSI reference definition of aperiodic CSI reporting is used.

- For mode-B, n_{CSI_ref} is the smallest value greater than or equal to , such that slot n- n_{CSI_ref} corresponds to a valid downlink slot, where Z' corresponds to the delay requirement as defined in Clause 5.4.

In the report, a condition met indicator for new beam RS is determined according to the measurement(s) triggering the first PUCCH transmission.

Note: Strong concern was raised by vivo on the necessity of the above proposal especially considering the RAN4 status.

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding Event-1 and Event-7, one PUCCH resource of first PUCCH can be associated with one or multiple CSI report configurations.

Agreement

On beam report transmission procedure for UE-initiated/event-driven beam reporting, regarding priority rules for CSI report multiplexing/dropping, UEI beam report for both mode-A and mode-B is prioritized over Semi-persistent CSI reports on PUCCH and Periodic CSI reports on PUCCH

- UEI beam report for mode-A > Aperiodic CSI report > UEI beam report (for mode-B) > Semi-persistent CSI reports on PUSCH

Note-1: The intra-UE multiplexing/prioritization rules of PUSCH with A-CSI for PUSCH is reused for UEI-BR for Mode A.

Note-2: How to capture the above is up to Editor.

9.2.2 CSI enhancements

Including support for up to 128 CSI-RS ports on FR1 and UE reporting enhancement for CJT and SRS port grouping for TDD low-complexity 6/8RX receiver.

R1-2503276 On 128 CSI-RS ports and UE reporting enhancement Huawei, HiSilicon

R1-2503352 Remaining issues on Rel-19 CSI enhancements vivo

R1-2503434 Remaining Details of Rel-19 Enhancements of CSI InterDigital, Inc.

R1-2503510 Remaining issues on CSI enhancements Spreadtrum, UNISOC

R1-2503555 Moderator Summary#1 on Rel-19 CSI enhancements: Round 1 Moderator (Samsung)

R1-2503556 Views on Rel-19 CSI enhancements Samsung

R1-2503669 Discussion on CSI enhancements ZTE Corporation, Sanechips

R1-2503711 Discussion on Rel-19 CSI Enhancements Tejas Network Limited

R1-2503787 Remaining issues on Rel-19 CSI enhancements CATT

R1-2503825 Discussion on CSI enhancements CMCC

R1-2503860 Discussion on the Remaining Issues of CSI Enhancement Rakuten Mobile, Inc

R1-2503877 Further discussion on the remained issues for CSI enhancement Xiaomi

R1-2503910 CSI enhancements for Rel. 19 MIMO Fraunhofer IIS, Fraunhofer HHI

R1-2503913 Discussion on CSI enhancements Lenovo

R1-2503917 Discussion on CSI enhancements NEC

R1-2504028 CSI Enhancement for NR MIMO Google

R1-2504062 Discussion of CSI enhancements Sony

R1-2504077 CSI enhancement for NR MIMO Phase 5 Nokia

R1-2504085 Remaining issues on Rel-19 CSI enhancements Fujitsu

R1-2504096 Discussion on CSI enhancements HONOR

R1-2504134 Discussion on CSI enhancements for NR MIMO Phase 5 ETRI

R1-2504229 CSI enhancements for Rel-19 MIMO OPPO

R1-2504389 Maintenance on CSI for >32 ports and UE-assisted CJT Qualcomm Incorporated

R1-2504445 CSI enhancements Sharp

R1-2504451 Maintenance on CSI enhancements for large antenna arrays and CJT Ericsson

R1-2504496 Discussion on CSI enhancements NTT DOCOMO, INC.

R1-2504549 Discussion on CSI enhancements for NR MIMO Phase 5 KDDI Corporation

R1-2503555 Moderator Summary#1 on Rel-19 CSI enhancements: Round 1 Moderator (Samsung)

Agreement

For the Rel-19 aperiodic standalone CJT calibration (CJTC) reporting, when ReportQuantity is ‘cjtc-Dd’ (delay offset), add the following definition of the measurement quantity in TS38.215 as follows (analogous to the Rel-18 TDCP):

- For FR1, the reference point shall be the antenna connector of the UE.

Agreement

For the Rel-19 Type-I SP codebook refinement for 48, 64, and 128 CSI-RS ports, when configured with port subset indication (from the Rel-18 SD NES Type-1), the actual number of ports (the number of 1s in the port-subsetIndicator bitmap) can correspond to a supported value of P_CSI-RS for the Rel-19 Type-I SP codebook (i.e. either 48, 64, or 128), or to a supported value of P_CSI-RSfor the Rel-15 Type-I SP codebook (i.e., either 2, 4, 8, 12, 16, 24, 32), respectively

· The supported number of ports for port subset of the full P_CSI-RS ports, is according to UE capability

Agreement

For the Rel-19 Type-II codebook refinement for 48, 64, and 128 CSI-RS ports based on the Rel-18 Type-II Doppler codebook, when the K_DOPPCSI-RS resource groups are configured for aperiodic CMR, where each CSI-RS resource group comprises K>1 aggregated NZP aperiodic CSI-RS resources, the triggering offset of an associated aperiodic CSI-IM follows the associated NZP CSI-RS resource(s) for CMR in the first slot (in the time domain).

Agreement

For the Rel-19 Type-II codebook refinement based on Rel-18 Type-II Doppler for 48, 64, and 128 CSI-RS ports, for Capability 1, further clarify the previous agreement that

R1-2504728 Moderator Summary#2 on Rel-19 CSI enhancements: Round 2 Moderator (Samsung)

Conclusion

For the Rel-19 Type-I and Type-II (except for Type-II Doppler) codebook refinement for 48, 64, and 128 CSI-RS ports, when the K>1 aggregated NZP aperiodic CSI-RS resources for CMR are within two consecutive slots, following the legacy spec, the aperiodic triggering offset configured with the NZP CSI-RS resource set for interference measurement is the same as that of the associated NZP CSI-RS resource set for CMR.

Conclusion

For the Rel-19 Type-II codebook refinement for 48, 64, and 128 CSI-RS ports based on the Rel-18 Type-II Doppler codebook, when the K_DOPP >1 NZP aperiodic CSI-RS resource groups for CMR are configured, following the legacy spec, the aperiodic triggering offset configured with the NZP CSI-RS resource set for interference measurement is the same as that of the associated NZP CSI-RS resource set for CMR.

Agreement

For the Rel-19 Type-I SP and Type-II codebook refinement for P=48, 64, and 128 CSI-RS ports with K>1 aggregated NZP aperiodic CSI-RS resources for CMR, to implement the previous agreements on the mapping from CSI-RS resource index/port index per resource and port index to CSI/PMI calculation

· In TS38.211, extend the enumeration of antenna port p=3000+p’ with p’=0 …P–1

· In TS38.214, remove the term ‘port index for CSI/PMI calculation’

9.2.3 Support for 3-antenna-port codebook-based transmissions

Including support for 3T3R and 3T6R SRS antenna switching.

R1-2503277 Discussion on 3-antenna-port UL transmission Huawei, HiSilicon

R1-2503353 Remaining issues on 3-antenna-port codebook-based uplink transmissions vivo

R1-2503435 Remaining Details of Rel-19 CB-based UL for 3TX UE InterDigital, Inc.

R1-2503438 Summary of Discussion on 3TX CB-based Uplink in RAN1#121 Moderator (InterDigital, Inc.)

R1-2503557 Views on Rel-19 3-antenna-port codebook-based transmissions Samsung

R1-2503670 Discussion on 3-antenna-port codebook-based transmissions ZTE Corporation, Sanechips

R1-2503723 Remaining issues for 3 Tx UL transmissions Ericsson Japan K.K.

R1-2503788 Maintenance on 3-antenna-port uplink transmission CATT

R1-2503914 Support for 3-antenna-port codebook-based transmissions Lenovo

R1-2504029 Uplink 3 Port Codebook based Transmission Google

R1-2504078 On the support for 3-antenna-port codebook-based transmissions Nokia

R1-2504230 Discussion on 3-antenna-port uplink transmissions OPPO

R1-2504313 Remaining issues on R19 MIMO 3Tx transmission Apple

R1-2504446 Support for 3-antenna-port transmission Sharp

R1-2504456 Discussions on 3-antenna-port UL transmission China Telecom

R1-2503437 FL Summary Support for 3TX CB-based Uplink; First Round Moderator (InterDigital, Inc.)

Conclusion

For codebook-based PUSCH transmission by a 3TX UE, PUSCH scheduling by DCI format 0_3 is not supported.

- Agreement: Adopt the following TP in red text for TS 38.214 section 6.1.1.1.

-------------------------------------------Unchanged parts are omitted----------------------------------

For codebook based transmission with three antenna ports, the UE determines its codebook subsets based on TPMI(s) and upon the reception of higher layer parameter codebookSubset in pusch-Config for PUSCH associated with DCI format 0_1 ~~or 0_3~~ and codebookSubsetDCI-0-2in pusch-Config for PUSCH associated with DCI format 0_2 which may be configured with 'nonCoherent'.

-----------------------------------------Unchanged parts are omitted------------------------------------------

9.2.44 Enhancement for asymmetric DL sTRP/UL mTRP scenarios

Including support for 2TA without CoresetPoolIdx association for asymmetric DL sTRP/UL mTRP.

R1-2503278 Enhancements for asymmetric DL sTRP/UL mTRP scenarios Huawei, HiSilicon

R1-2503304 Enhancement for asymmetric DL sTRP/UL mTRP scenarios MediaTek Inc.

R1-2503354 Remaining issues on asymmetric DL sTRP/UL mTRP scenarios vivo

R1-2503436 Remaining Details of Rel-19 Asymmetric mTRP Operation InterDigital, Inc.

R1-2503511 Enhancements for asymmetric DL sTRP/UL mTRP scenarios Spreadtrum, UNISOC

R1-2503558 Views on Rel-19 asymmetric DL sTRP/UL mTRP scenarios Samsung

R1-2503671 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios ZTE Corporation, Sanechips, China Telecom

R1-2503712 Enhancement for asymmetric DL sTRP UL mTRP Tejas Network Limited

R1-2503730 Enhancements on asymmetric DL STRP/UL MTRP scenarios Ofinno

R1-2503789 Remaining issues on asymmetric DL sTRP and UL mTRP scenarios CATT

R1-2503817 Enhancement for Asymmetric DL sTRP/UL mTRP Scenarios Panasonic

R1-2503826 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios CMCC

R1-2503878 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios Xiaomi

R1-2503915 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Lenovo

R1-2503929 Discussion on enhancements for asymmetric DL sTRP and UL mTRP scenarios NEC

R1-2503978 Remaining issues on asymmetric DL sTRP UL mTRP scenarios Ericsson

R1-2503986 Discussions on asymmetric DL sTRP/UL mTRP scenarios LG Electronics

R1-2504063 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Sony

R1-2504079 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Nokia

R1-2504135 Remaining issues in asymmetric UL MIMO operation ETRI

R1-2504173 Discussion on enhancements for asymmetric DL sTRP/UL mTRP scenarios Transsion Holdings

R1-2504231 Enhancements on asymmetric DL sTRP/UL mTRP scenarios OPPO

R1-2504298 Discussion on enhancement for asymmetric DL sTRP and UL mTRP scenarios Google

R1-2504314 Enhancements for asymmetric DL sTRP/UL mTRP scenarios Apple

R1-2504390 Enhancement for asymmetric DL sTRP and UL mTRP deployment scenarios Qualcomm Incorporated

R1-2504458 Enhancement for asymmetric DL sTRP/UL mTRP scenarios Sharp

R1-2504462 Discussion on asymmetric DL sTRP/UL mTRP scenarios TCL

Late submission

R1-2504463 Discussion on asymmetric DL sTRP/UL mTRP scenarios TCL

R1-2504497 Discussion on enhancement for asymmetric DL sTRP/UL mTRP scenarios NTT DOCOMO, INC.

R1-2504655 Summary #1 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)

Conclusion

When the UE transmits a PUCCH with HARQ-ACK information in slot n corresponding to the PDSCH carrying the MAC CE command updating PL offset of TCI state(s), the updated PL offset(s) shall be applied starting from the first slot that is after where μ is the SCS configuration for the PUCCH.

Conclusion

Regarding whether/how to reset the CLPC of PUSCH/PUCCH/SRS, no further additional enhancement in Rel-19

R1-2504656 Summary #2 on Rel-19 asymmetric DL sTRP/UL mTRP Moderator (OPPO)